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Abstract 


The  Innovative  Naval  COMbat  MANagement  Decision  Support  (INCOMMANDS) 
Technology  Demonstration  Program  (TDP)  seeks  to  research,  demonstrate  and  evaluate  new 
command  decision  support  concepts  for  the  HALIFAX  Class  frigate’s  command  and  control 
(C2)  system,  with  the  objective  of  improving  team  battlespace  awareness  and  increasing 
decision  speed  and  accuracy.  This  work  necessitates  the  design,  development  and  evaluation 
of  innovative  Operator  Machine  Interface  (OM1)  concepts  to  support  the  operator’s 
interaction  with  the  command  decision  support  concepts  developed  by  the  project  team.  The 
aim  of  this  document  is  to  incoiporate  recommended  standards  and  guidelines  that  should 
guide  and  inform  the  design  of  OMI  and  decision  aiding  concepts  developed  within  the 
INCOMMANDS  project  so  that  they  are  consistent  with  human  factors  best-practice.  The 
document  includes  guidance  on  creating  a  common  look  and  feel  that  is  compatible  with 
existing  systems,  yet  accommodates  new  developments  and  knowledge  and  the  design  and 
implementation  of  decision  aids  that  are  both  useful  and  useable.  In  addition,  guidance  is 
provided  on  the  selection  of  metrics  and  tools  for  the  evaluation  of  both  the  OMI  and  decision 
aids  for  compliance. 


Resume 


Le  programme  de  demonstration  technologique  (PDT)  du  concept  INCOMMANDS  (Innovative 
Naval  COMbat  MANagement  Decision  Support,  ou  Systeme  novateur  d’aide  a  la  decision  pour  la 
gestion  du  combat  naval)  vise  a  etudier,  a  demontrer  et  a  evaluer  de  nouveaux  concepts  d’aide 
aux  decisions  de  commandement  pour  le  systeme  de  commandement  et  de  controle  (C2)  de  la 
fregate  de  classe  HALIFAX,  dans  l’intention  d’ameliorer  la  connaissance  collective  de  l’espace 
de  bataille  et  d’augmenter  la  rapidite  et  la  justesse  des  decisions.  Ces  travaux  exigent  la 
conception,  1’ elaboration  et  1’ evaluation  de  principes  novateurs  d’ interface  operateur-machine 
(10M)  pour  appuyer  l’interaction  de  l’operateur  avec  les  concepts  d’aide  aux  decisions  de 
commandement  elabores  par  l’equipe  du  projet.  Ce  document  a  pour  but  d’integrer  des  normes  et 
des  lignes  directrices  recommandees,  qui  guideront  et  fac^onneront  l’elaboration  des  concepts 
d’lOM  et  d’aide  a  la  decision  arretes  dans  le  cadre  du  projet  INCOMMANDS  de  sorte  qu’ils 
correspondent  aux  meilleures  pratiques  des  facteurs  humains.  Le  document  integre  des  lignes 
directrices  en  vue  de  la  creation  d’une  presentation  uniforme  qui  soit  compatible  avec  les 
systemes  existants,  tout  en  tenant  compte  des  demiers  developpements  et  de  l’etat  des 
connaissances  pour  la  conception  et  la  mise  en  oeuvre  d’ aides  a  la  decision  a  la  fois  utiles  et 
utilisables.  On  y  trouve  egalement  des  lignes  directrices  sur  le  choix  des  indicateurs  et  des  outils 
pemiettant  d’evaluer  la  conformite  de  1’IOM  et  des  aides  a  la  decision. 
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Executive  summary 


INCOMMANDS  TDP:  Human  factors  design  and  evaluation 
guide: 

Sharon  McFadden;  DRDC  Toronto  TR  2009-062;  Defence  R&D  Canada  - 
Toronto;  May  2011. 

Introduction  or  background:  The  purpose  of  the  Innovative  Naval  COMbat  MANagement 
Decision  Support  Technology  Demonstration  Program  (INCOMMANDS  TDP)  is  to  develop, 
demonstrate,  and  evaluate  advanced  Above  Water  Warfare  (AWW),  Threat  Evaluation  and 
Weapons  Allocation  (TEWA)  command  decision  support  concepts  (i.e.,  decision  aids)  for  the 
command  team  of  the  Halifax  Class  Frigate  in  order  to  improve  overall  decision-making 
effectiveness.  This  work  necessitates  the  design,  development  and  evaluation  of  innovative 
Operator  Machine  Interface  (OMI)  concepts  to  support  the  operator’s  interaction  with  the 
command  decision  support  concepts  developed  by  the  project  team. 

The  purpose  of  this  document  is  to  inform  and  guide  the  design  and  development  of  Electronic 
Support  System  (ESS)  and  OMI  design  concepts  explored  within  the  INCOMMANDS  TDP.  The 
specific  objectives  are: 

•  To  incorporate  recommended  standards  and  guidelines  that  will  inform  the  design  of  OMI 
and  decision  aiding  concepts  developed  within  the  INCOMMANDS  project  so  that  they  are 
consistent  with  Human  Factors  best-practice,  compatible  with  existing  military  OMI  guides, 
and  employ  an  interface  style  with  which  operators  are  familiar; 

•  To  provide  common  human  factors  design  guidance  for  existing  decision  aids,  decision  aids 
under  development,  and  future  decision  aiding  concepts  within  the  context  of  Maritime 
command  and  control  (C2),  including  TEWA;  and, 

•  To  provide  general  guidance,  in  terms  of  suggested  metrics  and  tools,  for  the  evaluation  of  a 
proposed  OMI’s  and  ESS’s  compliance  with  the  guidelines. 

Results:  This  document  is  largely  an  integration  of  the  COMmand  Decision  Aiding  technology 
(COMDAT)  OMI  Style  Guide  [1]  and  the  INCOMMANDS  decision  support  guidelines  [2],  It  is 
comprised  of  24  sections.  The  first  six  sections  provide  background  and  supporting  material  as 
well  as  high  level  design  guidance.  Each  of  the  remaining  sections  is  devoted  to  a  specific  area  of 
design.  A  unique  component  of  this  guide  is  the  inclusion  of  recommended  measures  and 
methods  for  evaluating  whether  or  not  the  ESS  and  OMI  are  compliant  with  the  guidelines. 

Significance:  Consistent  decision  support  and  OMI  design  within  and  across  systems  contributes 
to  enhanced  usability.  This  guide  provides  the  development  team  with  a  way  to  ensure  design 
consistency  within  a  system  and  with  systems  fielded  in  similar  naval  environments.  The  benefits 
of  consistency  and  interoperability  between  systems  include  reduced  development  and  training 
costs  and  more  usable  decision  support  systems. 

Future  plans:  The  guidance  within  this  document  does  not  present  detailed  design  solutions  or 
exact  specifications.  These  will  be  developed  and  evaluated  by  the  development  teams  using,  in 
part,  the  evaluation  criteria  provided  in  here.  As  successful  solutions  are  developed,  they  should 
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be  captured  as  design  specifications  and  added  to  the  guidance  provided  in  this  document. 
Moreover,  it  is  recommended  that  project  managers  developing  decision  aids  for  Maritime  C2 
systems  refer  to  the  guidance  presented  in  this  document.  In  doing  so,  consistency  across  C2 
systems  within  the  naval  environment  should  be  achieved. 
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Sommaire 


PDT  INCOMMANDS  :  Guide  de  conception  et  devaluation  des 
facteurs  humains 

Sharon  McFadden;  DRDC  Toronto  TR  2009-062;  R  et  D  pour  la  defense  Canada 
-Toronto;  Maye  2011. 

Introduction  ou  contexte  :  Le  programme  de  demonstration  technologique  (PDT)  du  concept 
INCOMMANDS  (Innovative  Naval  COMbat  MANagement  Decision  Support,  ou  Systeme 
novateur  d’aide  a  la  decision  pour  la  gestion  du  combat  naval)  vise  a  elaborer,  a  demontrer  et  a 
evaluer  des  concepts  avances  d’aide  aux  decisions  de  commandement  en  situation  de  guerre  de 
surface  et  devaluation  de  la  menace  et  de  designation  des  armes  (TEW A)  (autrement  dit  les  aides 
a  la  decision)  accessibles  a  Tequipe  de  commandement  de  la  Legate  de  classe  HALIFAX,  afm 
d’ameliorer  l’efficacite  generate  du  processus  decisionnel.  Ces  travaux  exigent  T elaboration  et 
1’evaluation  de  concepts  novateurs  d’interface  operateur-machine  (IOM)  pour  appuyer 
Tutilisation  par  l’operateur  des  concepts  d’aide  aux  decisions  de  commandement  elabores  par 
Tequipe  du  projet. 

Ce  document  vise  a  etayer  et  a  orienter  la  conception  et  1’ elaboration  du  systeme  de  soutien 
electronique  (SSE)  et  les  concepts  d’elaboration  de  1’IOM  examines  dans  le  cadre  du 
PDT  INCOMMANDS.  Les  objectifs  sont  precisement  les  suivants  : 

•  Integrer  des  normes  et  des  lignes  directrices  recommandees  qui  guideront  et  faponneront 
T  elaboration  des  concepts  d’lOM  et  d’aide  a  la  decision  elabores  dans  le  cadre  du  projet 
INCOMMANDS  de  sorte  qu’ils  correspondent  aux  meilleures  pratiques  des  facteurs 
humains,  qu’ils  soient  compatibles  avec  les  guides  militaires  existants  sur  1’IOM  et  qu’ils 
emploient  une  interface  avec  laquelle  les  operateurs  sont  familiers; 

•  Assurer  une  direction  commune  en  matiere  de  conception  ergonomique  en  ce  qui  touche  les 
aides  a  la  decision  actuelles,  les  aides  a  la  decision  en  conception  et  les  concepts  d’aide  a  la 
decision  tuturs  dans  le  contexte  de  commandement  et  de  controle  (C2)  de  la  Marine,  ce  qui 
comprend  T  evaluation  de  la  menace  et  la  designation  des  aimes  (TEWA); 

•  Foumir  des  directives  en  ce  qui  touche  les  indicateurs  et  les  outils  servant  a  evaluer  dans 
quelle  mesure  1’IOM  et  le  SSE  proposes  sont  confoimes  aux  lignes  directrices. 

Resultats  :  Le  document  integre  en  grande  partie  le  guide  sur  1’IOM  de  la  technologie  d’aide  a  la 
decision  de  commandement  (COMDAT)  [1]  et  les  lignes  directrices  concemant  l’aide  a  la 
decision  INCOMMANDS  [2].  II  comporte  24  sections.  Les  six  premieres  sections  foumissent  des 
renseignements  de  base  et  des  elements  d’appoint,  ainsi  que  des  directives  de  haut  niveau  en 
matiere  de  conception.  Chacune  des  autres  sections  porte  sur  un  domaine  conceptuel  en 
particulier.  Une  caracteristique  unique  de  ce  guide  est  1’ inclusion  d’ indicateurs  et  de  methodes 
recommandes  peimettant  d’evaluer  si  le  SSE  et  1’IOM  sont  confomies  aux  lignes  directrices. 

Portee  :  Des  concepts  uniformises  d’aide  a  la  decision  et  d’lOM  facilitent  Tutilisation  des 
systemes.  Ce  guide  procure  a  Tequipe  de  developpement  un  moyen  d’assurer  l’uniformite 
conceptuelle  au  sein  d’un  systeme  aussi  bien  qu’entre  les  systemes  mis  en  place  dans  des 
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environnements  maritimes  semblables.  L’uniformite  et  l’interoperabilite  entre  les  systemes 
procurent  entre  autres  l’avantage  de  reduire  les  ffais  de  developpement  et  de  formation  et  de 
rendre  l’appui  decisionnel  plus  convivial. 

Recherches  futures  :  Ce  document  ne  presente  pas  de  solutions  conceptuelles  detaillees  ni  de 
specifications  precises.  Celles-ci  seront  elaborees  et  evaluees  par  les  equipes  de  developpement, 
qui  se  fonderont  en  partie  sur  les  criteres  devaluation  enonces  dans  le  document.  Au  fur  et  a 
mesure  que  des  solutions  utiles  seront  elaborees,  on  devrait  les  noter  en  tant  que  specifications 
conceptuelles  et  les  aj  outer  aux  lignes  directrices  figurant  dans  ce  document.  Par  ailleurs,  il  est 
recommande  que  les  gestionnaires  de  projet  qui  elaborent  des  aides  a  la  decision  destinees  aux 
systemes  C2  de  la  Marine  se  reportent  aux  lignes  directrices  figurant  dans  ce  document.  On 
devrait  ainsi  reussir  a  uniformiser  tous  les  systemes  C2  du  milieu  maritime. 


VI 
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1  Introduction 


1.1  Background 

The  purpose  of  the  Innovative  Naval  COMbat  MANagement  Decision  Support  Technology 
Demonstration  Program  (INCOMMANDS  TDP)  is  to  develop,  demonstrate  and  evaluate 
advanced  Above  Water  Warfare  (AWW)  Threat  Evaluation  and  Weapons  Allocation  (TEWA) 
command  decision  support  concepts  (i.e.,  decision  aids)  for  the  command  team  of  the  Halifax 
Class  Frigate  in  order  to  improve  overall  decision-making  effectiveness. 

A  central  premise  underlying  the  INCOMMANDS  TDP  is  that  Canadian  warships  will  be 
required  to  have  advanced  and  innovative  command  and  control  (C2)  decision  aid  capabilities 
that  will  improve  operator  decision-making  effectiveness  in  the  context  of  TEWA.  Advances  in 
threat  technology,  the  increasing  difficulty  and  diversity  of  air,  land,  open-ocean,  and  littoral 
scenarios,  and  the  volume  of  data  and  information  to  be  processed  under  time -critical  conditions 
pose  significant  challenges  to  tactical  C2,  in  particular  TEWA.  The  dynamic  environment  in 
which  these  activities  are  conducted  is  one  of  high  risk  and  stress  as  it  includes  organised, 
intelligent,  lethal  threats.  It  is  also  inherently  uncertain  due  to  the  imprecise  and  incomplete 
nature  of  sensor  data  and  intelligence,  which  places  variable  and  unpredictable  demands  on 
decision  makers.  These  and  other  factors  lead  to  increased  demands  for  time-pressured  decision 
making  in  ambiguous  tactical  situations.  They  also  contribute  to  a  rapidly  growing  data  overload 
problem  for  a  ship’s  Command  Team.  Hence  the  objective  of  the  INCOMMANDS  TDP  is  to 
improve  team  battlespace  awareness,  and  increase  decision  speed  and  accuracy  under  high- 
workload,  high-stress,  and  uncertain  conditions.  The  intention  is  that  the  decision  aiding  concepts 
will  present  information  and  provide  decision  recommendations  in  such  a  way  as  to  reduce  the 
mental  demands  placed  on  an  operator.  This  necessitates  the  design,  development,  and  evaluation 
of  innovative  Operator  Machine  Interface  (OM1)  concepts  to  support  the  operator’s  interaction 
with  the  proposed  decision  support  concepts. 

1 .2  Objectives 

The  goal  of  this  document  (hereafter  called  the  “Guide”)  is  to  inform  and  guide  the  design  and 
development  of  the  Electronic  Support  Systems  (ESS)  and  OMI  design  concepts  explored  within 
the  INCOMMANDS  TDP.  In  order  to  achieve  this  goal,  the  objectives  are  as  follows: 

•  To  incoiporate  recommended  standards  and  guidelines  that  will  inform  the  design  of  OMI 
and  decision  aiding  concepts  developed  within  the  INCOMMANDS  project  so  that  they  are 
consistent  with  Human  Factors  best-practice,  compatible  with  existing  military  OMI  guides, 
and  employ  an  interface  style  with  which  operators  are  familiar; 

•  To  provide  common  OMI  design  guidance  for  existing  decision  aids,  decision  aids  under 
development,  and  future  decision  aiding  concepts,  within  the  context  of  Maritime  C2, 
including  TEWA;  and, 

•  To  provide  general  guidance,  in  terms  of  suggested  metrics  and  tools,  for  the  evaluation  of  a 
proposed  OMFs  and  ESS’s  compliance  with  the  guidelines. 
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1 .3  Scope  of  document 

This  document  does  not  present  detailed  design  solutions  or  exact  specifications.  As  well  as 
proving  to  be  technically  difficult,  time  consuming  and  prone  to  obsolescence  over  time,  to  do  so 
would  inhibit  the  creative  scope  of  the  development  team.  Instead,  this  document  presents  generic 
guidance  to  support  the  development  of  ESS  and  OMI  design  concepts.  The  detailed  design 
solutions  will  be  developed  and  evaluated  by  the  development  teams  using,  in  part,  the  evaluation 
criteria  provided  in  this  document.  As  successful  solutions  are  developed,  they  should  be  captured 
as  design  specifications  and  added  to  the  guidance  provided  in  this  document.  Finally,  future 
Maritime  C2  projects  should  refer  to  the  guidance  presented  in  this  document.  In  doing  so, 
consistency  across  all  systems  that  are  developed  should  be  achieved. 

1 .4  Organization  of  the  Guide 

The  Guide  is  comprised  of  24  sections.  The  overall  organization  is  as  follows: 

•  Sections  1  through  6  provide  background  and  supporting  material. 

•  Sections  6  through  24  comprise  the  body  of  the  Guide. 

Each  of  the  guidance  sections  is  devoted  to  a  specific  area  of  design.  Since  the  Guide  is  an 
integration  of  the  COMmand  Decision  Aiding  Technology  (COMDAT)  OMI  Style  Guide  [1]  and 
the  INCOMMANDS  decision  support  guidelines  [2],  the  organization  of  the  different  sections 
and  of  the  guidelines  within  a  section  are  not  identical. 

1.4.1  Guideline  format 

Each  guideline  topic  contains  the  following  information: 

•  Guideline  number.  A  unique  reference  number  given  to  each  guideline,  or  set  of 
guidelines,  to  enable  rapid  search  for  a  particular  guideline  (e.g.,  7.1.1). 

•  Guideline  title.  A  short  title  that  summarizes  the  topic  of  the  guide line(s)  (e.g..  Employ 
operator  centered  principles). 

•  Guideline(s).  A  list  of  guidelines  relevant  to  the  topic. 

•  Source.  A  reference  for  the  source  document(s)  from  which  the  guideline(s)  was  (were) 
taken.  The  full  reference  for  each  source  is  shown  in  Section  3  and  in  the  reference  list  at  the 
end  of  the  document. 

•  Discussion.  Where  relevant,  supporting  evidence,  caveats,  and/or  further  discussion  of  the 
guidelines  are  presented  in  this  section.  If  a  paragraph  within  the  discussion  applies  to  a 
specific  guideline,  the  paragraph  is  labelled  “Gx”  where  x  is  the  guideline  number. 

•  Evaluation  methods  and  measures.  Evaluation  methods  and  measures  are  provided  that 
will  enable  the  developer  to  demonstrate  compliance  with  the  guideline(s).  These  measures 
are  described  in  Section  6. 

•  Relationship  to  other  guidelines.  Relevant  guidelines  (and  the  Guideline  Number)  to  the 
topic  are  presented  here.  Cross-referencing  should  make  it  less  likely  that  related  guidelines 
are  overlooked. 
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1.5 


Conventions  used  in  this  style  guide 


1.5.1  Terminology 

1 .5.1.1  Use  of  Shall  Versus  Should 

Many  guideline  documents  draw  a  distinction  between  mandatory  (or  shall)  provisions,  and 
recommended  (or  should)  provisions.  All  of  the  provisions  in  this  document  are  written  as 
mandatory  and  use  shall.  The  intent  of  the  language  is  not  to  imply  that  all  guidelines  presented  in 
this  document  are  required.  The  intent  is  that  the  system  developer  follows  the  guidelines 
presented  herein  if  the  design  uses  a  feature  described  in  this  document.  The  language  of  shall 
rather  than  should  was  chosen  for  historical  contractual  reasons.  Historically,  and  often  by 
training,  developers  focus  on  the  required  provisions  and  avoid  guidance  that  is  not  required. 

1.5.1. 2  Operators  versus  users 

Throughout  this  document  the  terms  Users  and  Operators  are  used  interchangeably  to  refer  to  the 
crewmembers  that  operate  the  Command  and  Control  System  (CCS).  The  terms  users  and 
operators  do  not  refer  to  members  of  the  design  or  engineering  team. 

1.5.1. 3  Use  of  term  Electronic  Support  System  (ESS) 

Given  the  propensity  of  computer-based  systems  that  assist  the  operator  in  a  myriad  of  mental  and 
physical  activities  (e.g.,  decision  making  aids,  decision  aids,  automation,  adaptive  automation, 
intelligent  automation,  intelligent  adaptive  interfaces,  expert  systems,  knowledge-based  systems, 
data  fusion,  and  information  fusion)  to  varying  degrees  of  autonomy  (e.g.,  tool,  aid,  associate, 
autonomous  agent)  and  sophistication  (e.g.,  assistant,  associate,  or  coach),  the  generic  term 
Electronic  Support  System  (ESS)  has  been  used  in  this  document  to  refer  to  all  of  the  systems,  and 
similar  systems,  that  are  cited  above.  An  electronic  support  system  is  defined  as: 

•  A  sophisticated  computer-based  system,  which  embodies  domain  expertise,  used  to  assist 
decision  makers  in: 

■  Acquiring,  fusing,  modelling  and  displaying  information; 

■  evaluating  and  integrating  information; 

■  Presenting  a  synthesized  picture  of  the  situation; 

■  Making  decisions;  and, 

■  Implementing  a  course  of  action. 


1 .5.2  Representation  of  keys 

Representations  in  this  document  such  as  “<  >”  are  used  to  refer  to  input  device  selections  (or 
sequence  of  selections)  assigned  to  the  function  described  by  "<  >".  Thus,  <Shift>  means  press 
the  Shift  key. 
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1.5.3  Selection  of  symbology 


Throughout  the  document  the  provisions  call  for  adherence  to  the  Naval  Tactical  Data  System 
(NTDS)  symbols  unless  superseded  by  specified  symbology.  The  intent  of  the  caveat  is  to 
identify  the  possibility  that  the  Canadian  Forces  may  move  to  STANAG  4420  [3]  or  Military 
Standard  2525  (Common  Warfighting  Symbology)  [4]  as  the  common  symbology  base. 

1 .6  Use  of  Microsoft  Windows  OMI  style  guide 

In  Maritime  CCSs,  the  core  OMI  style  has  been  Open  Source  Foundation  (OSF)/Motif. 
Developers  of  Maritime  CCSs  have  been  directed  to  the  OSF/Motif  style  guide  and  tool  kit.  Use 
of  the  OSF/Motif  style  guide  was  intended  to  promote  consistency  within  applications  and  to 
promote  interoperability  among  various  defence  systems.  Consistency  among  OMls  results  in 
reduced  training,  fewer  errors,  and  increased  effectiveness. 

The  use  of  OSF/  Motif  styles,  does  promote  and  define  consistencies  among  defence  systems,  but 
does  not  build  on  the  lifetime  of  computer  experience  of  Canadian  operators.  Computing  has 
changed  rapidly  over  the  past  several  decades.  The  platform  with  which  most  Canadians  are 
familiar  is  Microsoft  Windows.  Thus,  this  Guide  follows  Microsoft  Windows  styles.  By  using  the 
Microsoft  Windows  styles,  the  new  applications  will  build  on  the  external  (non-military)  training 
that  the  operators  have  received.  Operators  will  be  able  to  transfer  the  learning  that  they  have 
obtained  throughout  their  previous  computer  experiences  to  the  INCOMMANDS  systems  and 
will  not  have  to  learn  unique  conventions  for  similar  computing  functions.  The  CCS  applications 
will  be  consistent  with  the  conventions  and  tools  that  the  operators  have  already  learned  during 
other  computing  activities. 

The  migration  from  OSF/Motif  styles  to  Microsoft  Windows  styles  is  not  intended  to  imply  the 
use  of  a  Microsoft  operating  system.  Any  operating  system  may  be  used.  The  goal  is  not  to 
require  a  specific  operating  system  but  instead  to  produce  effective  systems  with  a  common  look 
and  feel.  Flowever,  the  use  of  a  software  development  environment  that  employs  frames  and 
widgets  consistent  with  Microsoft  Windows  styles  is  recommended. 

When  the  source  documents  refer  to  the  OSF/Motif  styles,  the  current  document  has  edited  the 
references  so  that  they  call  out  the  Microsoft  windows  conventions.  The  Microsoft  Windows 
guidelines  in  their  entirety  are  available  commercially  [5].  Thus  for  the  most  part  they  are  not 
repeated  here.  Where  necessary,  the  guidance  has  been  tailored  for  the  unique  Maritime  CCS 
requirements. 

Appropriate  copyright  permissions  for  Motif,  Microsoft,  or  any  protected  materials  should  be 
sought  before  incoiporating  copyrighted  materials  or  designs  into  an  OMI. 
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2  Using  the  INCOMMDANDS  human  factors  design 
and  evaluation  guide 


Consistent  ESS  and  OMI  design  within  and  across  systems  contributes  to  enhanced  usability.  For 
reasons  discussed  in  the  previous  section,  the  need  for  consistency  in  the  development  of 
INCOMMANDS  decision  support  systems  and  interfaces  is  particularly  critical.  This  Guide 
provides  the  development  team  with  a  means  to  ensure  consistency  within  a  system  and  across 
systems.  The  benefits  of  consistency  and  interoperability  between  systems  include  reduced 
development  and  training  costs  and  a  more  usable  ESS. 

The  goal  of  the  Guide  is  to  provide  information  that  permits  the  developer  to  build  on  existing 
design  solutions  and  operations  knowledge  while  at  the  same  time  creating  new  and  effective 
designs.  Thus,  it  includes  high-level  design  guidance  as  well  as  detailed  guidance.  Unlike  most 
existing  design  guidance,  the  Guide  includes  recommendations  on  methods  for  establishing 
compliance  with  specified  guidelines.  Often,  compliance  is  based  on  a  heuristic  evaluation  of  the 
proposed  OMI  by  a  human  factors  practitioner.  While  this  may  be  sufficient  for  assessing 
specific,  well-defined  aspects  of  the  OMI  design,  it  is  less  satisfactory  for  assessing  less 
prescriptive  and  more  abstract  guidance.  Examples  might  include  statements  such  as  “the  system 
shall  maintain  operator  situation  awareness”  or  “all  colours  shall  be  easily  discriminated”.  The 
addition  of  recommended  methods  for  evaluating  compliance  makes  the  Guide  more  useful  to 
project  managers  who  use  it  as  part  of  a  system  specification. 

To  use  the  Guide  effectively,  the  processes  related  to  it  must  be  incorporated  into  the  contractor’s 
existing  development  processes.  The  greatest  cost  benefit  will  be  achieved  when  the  Guide  is  used 
from  the  beginning  of  the  development  effort.  This  includes  incorporation  of  the  recommended 
evaluation  processes. 

The  whole  ESS  and  OMI  development  team  should  be  aware  of  the  general  contents  of  the  Guide. 
In  addition,  the  team  should  assign  one  person  to  be  the  lead  on  the  implementation  of  the 
guidelines  and  the  evaluation  of  the  design  concepts.  That  person  should  have  a  detailed 
understanding  of  the  guidelines  and  evaluation  methodologies.  He/she  should  be  aware  of  the 
design  solutions  developed  by  the  team  members  and  should  resolve  competing  design  options  so 
that  they  are  optimized  for  the  operators.  Resolving  competing  design  options  as  they  occur 
reduces  the  amount  of  design  work  required. 

Each  design  solution  and  evaluation  should  be  documented  in  a  project  human  factors  design  and 
evaluation  guide  (hereafter  called  the  “Project  Guide”).  Thus,  the  Project  Guide  will  evolve  to 
become  a  description  of  the  design  decisions  and  their  relative  merits.  The  Project  Guide  lead 
should  be  responsible  for  ensuring  that  the  project  solutions  are  consistent  with  the  Project  Guide 
and  have  been  suitably  evaluated. 

The  Guide  was  developed  to  be  as  inclusive  as  possible.  For  any  given  decision  support  and/or 
OMI  design  many  sections  will  not  be  applicable.  If  the  Project  Guide  lead  determines  that  a 
specific  section  is  not  applicable  to  the  emerging  design,  it  can  be  omitted.  For  example,  if  the 
design  does  not  include  graphs,  guidance  on  the  graph  design  can  be  omitted.  Any  decision  to 
omit  a  section  should  be  documented.  If  it  is  appropriate  and  works  well  with  the  existing 
coiporate  processes,  documentation  of  decisions  can  be  treated  in  much  the  same  way  as  a 
compliance  matrix  for  other  requirements. 
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The  Guide  can  be  formatted  in  an  abbreviated  table  format  with  additional  columns  as  required 
beside  each  item  in  the  guide  as  is  done  in  a  compliance  matrix.  The  disposition  of  each  item  can 
be  documented  in  the  column  alongside  the  style  guide  item.  The  project  office  can  use  a 
dedicated  column  for  comments,  questions,  or  to  sign  off  on  any  agreed  deviations.  The 
contractor  should  use  a  process  to  implement  the  Guide  that  works  well  with  the  entire  corporate 
development  process.  Using  the  corporate  process,  the  disposition  of  each  item  in  the  Guide 
should  be  documented.  If  a  design  solution  is  reached  that  is  not  addressed  in  the  Guide,  the 
solution  and  the  supporting  evaluation  method  should  be  added  to  the  Project  Guide.  Conflicts 
between  the  Guide  and  the  Project  Guide  should  be  resolved  between  the  project  office  and  the 
contractor’s  team.  Similarly,  the  project  office  should  review  any  additions  to  the  Project  Guide 
that  are  not  addressed  in  the  Guide. 

Development  of  new  designs  and  technologies  is  rapid.  It  is  not  possible  to  predict  all  of  the  new 
and  effective  design  options  that  will  be  developed.  The  Guide  is  intended  to  support  design 
creativity,  not  to  limit  it.  As  new  technologies  and  decision  support  concepts  are  developed  they 
should  be  tested  for  usability  within  the  complete  operational  context  using  the  methodologies 
recommended  in  the  Guide.  Successful  solutions  should  be  captured  as  part  of  the  specific  design 
being  developed.  If,  for  example,  an  operationally  effective  3-dimensional  (3D)  display  is 
developed,  then  both  the  Guide  and  the  Project  Guide  should  be  updated  with  guidelines  covering 
the  elements  of  that  display  that  make  it  effective.  For  the  purposes  of  the  project,  the  design 
team,  whether  that  team  is  comprised  of  a  single  designer  or  a  larger  team,  will  have  a 
documented  reference,  so  that  throughout  the  project,  any  3D  displays  will  have  the  same  look 
and  feel. 
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3  Source  documents 


The  COMDAT  OMI  Style  Guide  [1]  and  the  INCOMMANDS  decision  support  guidelines  [2] 
integrated  guidance  from  multiple  documents  and  tailored  them  for  use  in  the  development  and 
evaluation  of  prototype  CCSs  such  as  the  INCOMMANDS  Technology  Demonstrator  (TD).  A 
list  of  these  source  documents  is  provided  below.  As  part  of  the  tailoring  process,  statements  from 
the  different  source  documents  have  been  incorporated  as  originally  written  or  have  been 
modified  as  appropriate  for  the  Canadian  operating  environment  or  to  reflect  more  recent 
research.  Thus,  citation  of  a  source  does  not  imply  that  the  originators  of  the  sources  have  read  or 
approved  of  the  statements  or  provisions  presented  in  this  guide. 

The  knowledge  base  from  which  these  guidelines  have  been  extracted  varies  extensively  in  its 
reliability  and  depth.  In  some  cases,  especially  with  the  OMI  guide,  the  guidelines  are  based  on 
multiple  studies  and/or  extensive  experience.  In  other  cases,  such  as  guidelines  for  ESS  or 
complex  displays,  the  knowledge  base  is  less  mature  and  many  of  the  guidelines  have  not  been 
substantiated  by  experience.  To  provide  the  reader  with  an  estimate  of  the  quality  of  the  guidance, 
the  source  documents  are  organized  by  type  of  publication.  In  some  instances,  the  information  in 
the  original  COMDAT  OMI  Style  Guide  was  derived  from  specialized  professional  knowledge 
and  a  review  of  the  COMDAT  TD.  In  such  cases,  the  supporting  documents  may  not  be  available 
for  referral  or  may  represent  generally  accepted  human  factors  professional  knowledge.  In  those 
instances,  Unger  Campbell  and  Associates,  the  corporate  author  of  the  COMDAT  OMI  Style 
Guide  is  cited  as  the  source. 

The  documents  listed  in  Table  1  are  cited  within  the  body  of  the  report  using  the  acronyms  in 
column  one.  One  primary  source  document  for  the  OMI  guidance  was  the  Theater  Battle 
Management  Human  Computer  Interface  Specification  (TBM)  [6].  Throughout  TBM,  the  original 
source  documents  were  also  cited.  The  COMDAT  OMI  Style  Guide  retained  the  source  references 
identified  in  TBM  (rather  than  citing  TBM  as  the  primary  source).  However,  many  of  those 
sources  are  no  longer  available.  Thus,  this  guide  cites  TBM.  The  COMDAT  OMI  Style  Guide  or 
TBM  can  be  consulted  if  further  details  about  the  original  source  of  the  information  are  required. 

Table  1:  List  of  source  documents 


Acronym 

Document  Title 

Military  standards 

DEFSTD25 

Ministry  of  Defence  (1987),  Human  factors  for  designers  of  equipment,  (Def 
Stan  00-25  (Part  1)  Issue  2),  Ministry  of  Defence,  Whitehall,  London,  U.K.  [7] 

MH761 

Department  of  Defense  (1989).  Human  engineering  guidelines  for  management 
information  systems,  (M1L-HDBK-761A),  Department  of  Defense, 

Washington,  D.C.  [8] 

MS1472F 

Department  of  Defense  (1999),  Department  of  Defense  Design  Criteria 

Standard:  Human  Engineering,  (M1L-STD-1472F),  Department  of  Defense, 
Washington,  D.C.  [9] 

Commercial  standards 
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Acronym 

Document  Title 

MSWUE 

Microsoft  Corporation  (1999),  Microsoft  Windows  user  experience:  Official 
guidelines  for  user  interface  developers  and  designers,  Redmond,  WA: 

Microsoft  Press.  [5] 

Book  chapters 

Endsley96 

Endsley,  M.  D.  (1996),  Automation  and  situation  awareness,  In  R. 

Parasuraman  and  M.  Mouloua  (Eds.),  Automation  and  Human  Performance: 
Theory  and  Applications  (pp.  163-181).Mahwah,  NJ:  Lawrence  Erlbaum.  [10] 

Nielsen94 

Nielsen,  J.  (1994),  Heuristic  Evaluation,  In  Nielsen,  J.,  and  Mack,  R.L.  (Eds.), 
Usability  Inspection  Methods,  John  Wiley  &  Sons,  New  York,  NY.  [11] 

Zachary97 

Zachary,  W.  W.  and  Ryder,  J.  M.  (1997),  Decision  support  systems:  Integrating 
decision  aiding  and  decision  training,  In  M.  G.  Helander,  T.  K.  Landauer,  and 

P.  V.  Prabhu  (Eds.),  Handbook  of  Human-Computer  Interaction,  pp  1235- 
1258.  Amsterdam,  The  Netherlands:  Elsevier  Science  B.V.  [12] 

Technical  reports 

AHCI 

Toms,  M.,  Williamson,  J.,  and  Cone,  S.  (1998),  Aviation  Human-Computer 
Interface  (AHCI)  Style  Guide,  (Report  No.  64201-97U/61223),  Veridian,  Veda 
Operations,  Dayton  Ohio.  [13] 

CSFAB 

Osga,  G.  and  Kellmeyer,  D.  (2000),  Combat  Systems  Functional  Allocation 
Board  Human-System  Interaction  (HS1)  style  guide.  Version  1.0,  (Draft)  Space 
and  Naval  Warfare  Systems  Command,  San  Diego,  CA.  [14] 

DISA 

Defense  Information  Systems  Agency  ( 1 994),  Department  of  Defense 

Technical  Architecture  Framework  for  Information  Management:  Volume  8: 
Department  of  Defense  HC1  Style  Guide,  Defense  Information  Systems 

Agency,  Washington,  D.C.[15] 

Etandbook  5 

MON1ME  AHWG  of  the  AUSCANNZUKUS  C3  Committee  (1997), 

Handbook  5 :  Guidelines  for  Maritime  Information  Management, 
AUSCANNZUKUS.  [16] 

HFDATC 

Cardosi,  K.  M.  and  Murphy,  E.  D.  (1995),  Human  factors  in  the  design  and 
evaluation  of  air  traffic  control  systems,  (DOT/FAA/RD-95/3;  DOT-VNTSC- 
FAA-95-3),  John  A.  Volpe  National  Transportation  Systems  Center, 

Cambridge,  MA.[17] 

HFDS 

Ahlstrom,  V.  and  Longo,  K.  (2003),  Human  Factors  Design  Standard  (HFDS) 
for  acquisition  of  commercial  off-the-shelf  subsystems,  non-developmental 
items,  and  developmental  systems,  (DOT/FAA/CT-03/05;  HF-STD-001),  U.S. 
Department  of  Transportation,  Atlantic  City,  NJ.  [18] 
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Acronym 

Document  Title 

NOSTP 

Canadian  Forces  Naval  Operations  School  (2001),  Naval  operations  school 
training  publication.  (NOSTP  200B),  Maritime  Command.  [19] 

R/SAOC 

Unger  Campbell,  G.  (1996),  NORAD  R/SAOC  Modernization  Project.  Human 
factors  usability  review,  (DC1EM-96-CR-21),  Unger  Campbell  and  Associates, 
Delta,  BC.  [20] 

TBM 

Bowen  C.  D.  (1994),  Theatre  Battle  Management  Human  Computer  Interaction 
(HC1)  Specification,  (MP  94B0000036),  MITRE,  Bedford  MA.  [6] 

Journal  articles 

Endsley99 

Endsley,  M.R.  and  Kaber,  D.B.  (1999),  Level  of  automation  effects  on 
performance,  situation  awareness  and  workload  in  a  dynamic  control  task, 
Ergonomics,  42(3),  462-492.  [21] 

Parasuraman97 

Parasuraman,  R.  and  Riley,  V.  (1997),  Humans  and  automation:  Use,  misuse, 
disuse,  abuse,  Human  Factors,  39(2),  230-253.  [22] 

SheridanOO 

Sheridan,  T.B.  (2000),  Function  allocation:  algorithm,  alchemy  or  apostasy? 
International  Journal  of  Human-Computer  Studies,  52,  203-216.  [23] 

Conference  proceedings 

Hutchins99 

Hutchins,  S.G.,  Morrison,  J.G.,  and  Kelly,  R.T.  (1999),  Principles  for  aiding 
complex  military  decision  making.  In  Proceedings  of  the  Second  International 
Command  and  Control  Research  and  Technology >  Symposium.  Monterey,  CA. 
[24] 

Other 

UCA 

Unger  Campbell  and  Associates,  human  factors,  usability,  and  domain 
expertise. 
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4  Design  decision  filters 


The  design  decision  filters  are  the  system  characteristics  that  determine  how  general  OM1 
guidelines  are  defined  for  a  specific  system.  Design  decision  filters  include  the  characteristics  of 
the  user  population,  the  physical  environment,  and  the  devices  used  to  access  the  software. 

4.1  User  population 

This  document  is  intended  for  developers  who  develop  software,  technical  demonstrators,  or 
prototypes  to  be  used  by  Maritime  CCS  operational  personnel.  However,  it  is  intended  to  support 
operational  personnel  without  advanced  software  skills.  They  will  have  training  on  the  system  but 
the  training  should  not  be  used  to  compensate  for  poor  design. 

4.2  User  skills  and  experiences 

Operators  of  the  INCOMMANDS  system  will  have  a  range  of  experience  from  novice 
crewmembers  to  veterans  with  many  years  of  experience.  Familiarity  with  a  system,  frequency  of 
use,  and  training  all  affect  the  design.  The  design  team  should  ensure  that  all  levels  of  operator 
expertise  are  supported  and  that  support  for  one  level  of  expertise  does  not  interfere  with  the 
performance  of  operators  with  different  levels  of  expertise. 

4.3  Physical  environment 

The  working  environment  impacts  the  system  design.  The  working  environment  for 
INCOMMANDS  is  a  shipboard  operations  room.  Examples  of  design  considerations  resulting 
from  the  working  environment  are  presented  below: 

•  Colours.  Screen  colours  chosen  must  be  compatible  with  both  low  ambient  operations  room 
lighting  and  with  the  red  lighting  used  to  maintain  dark  adaptation. 

•  Font  size.  Font  sizes  must  be  larger  than  is  required  for  a  normal  office  environment. 

•  Cursor  targets.  The  shipboard  environment  is  subject  to  motion;  accordingly,  the  pointing 
device  and  on-screen  target  areas  for  the  cursor  must  be  large  so  that  fine  motor  control  is 
not  required. 
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5  High  level  design  guidance 


The  OMI  and  ESS  are  aspects  of  a  system's  design  that  directly  affect  user  experience.  Good  OMI 
and  ESS  designs  incorporate  all  of  the  necessary  functionality,  improve  operational  effectiveness, 
and  are  easy  to  learn.  Conversely,  poor  designs  are  difficult  to  use,  induce  user  errors,  reduce 
operational  effectiveness,  and  increase  the  operator  training  requirements. 

The  designer  has  multiple  ways  to  implement  system  functionality.  The  challenge  is  to 
incorporate  these  options  into  an  overall  design  that  results  in  a  good  OMI  and  effective  decision 
support.  Both  should  integrate  the  operator  with  the  system  and  achieve  the  following  goals: 

•  Consistency 

•  Interoperability 

•  Usability 

5.1  Consistency 

One  of  the  major  goals  of  the  Guide  is  to  enforce  consistency.  Consistency  is  not  just  a  question 
of  interface  design  but  includes  ensuring  that  the  system’s  tasks  and  structure  match  the 
operator’s  tasks  and  decision  making  processes.  Successful  C2  relies  on  information  being 
presented  in  a  manner  that  contributes  to  the  operators’  knowledge  of  the  tactical  situation;  the 
ability  to  access  information  and  to  convert  it  to  knowledge  is  enhanced  if  the  OMI  is  consistent. 
OMI  design  consistency  permits  the  operators  to  attend  to  the  information  supplied  by  the  system 
rather  than  to  the  system  itself  [25].  If  the  OMI  is  consistent  throughout  the  application,  and  with 
other  computer  experiences,  operators  do  not  need  to  devote  attention  to  details  of  operating  the 
software  controls  and  displays.  Instead,  cognitive  processing  is  focused  on  the  tactical 
information.  Each  instance  of  inconsistency  is  likely  to  produce  unnecessary  cognitive  processing 
and  affect  the  cognitive  processing  available  to  the  decision  maker  for  the  actual  combat  tasks. 
The  INCOMMANDS  OMI  therefore  shall  be  designed  to  be  consistent;  appearing,  behaving  and 
responding  the  same  throughout.  The  following  types  of  consistency  shall  be  considered: 

•  Consistency  with  the  current  Halifax  Class  CCS.  Platform  conventions  shall  be  followed 
where  practical. 

•  Consistency  with  existing  military  human  factors  standards.  These  include  but  are  not 
limited  to  MIL-STD  1472F  [9],  DEF-STD-00-25  [7],  and  MIL-HDBK-46855A  [26]. 

•  Visual  consistency  (general  OMI  layout  “look  and  feel”).  The  same  information  shall  be 
presented  in  the  same  location  on  all  screens  and  dialogue  boxes  and  it  shall  be  formatted  in 
the  same  way  to  facilitate  recognition.  Menus  shall  be  presented  in  a  consistent  format 
throughout  the  system  and  shall  be  readily  available  at  all  times. 

•  Consistency  with  operator  expectations.  Display-control  relationships  must  be  compatible 
with  the  operator’s  expectations,  and  require  minimal  processing  to  extract  the  information 
from  the  system  [25].  Operators  who  have  been  trained  on  a  software  system,  or  who  use  a 
system’s  controls  frequently,  access  the  controls  by  the  location  of  the  controls  rather  than 
by  the  labels  per  se.  The  labels  and  icons  are  used  to  confirm  the  identity  of  the  control 
rather  than  to  locate  them.  Operators  expect  specific  functions  to  be  located  in  known 
locations  on  the  display.  There  is  a  negative  transfer  of  training  if  the  controls  are  not 
located  in  consistent  places.  Negative  transfer  is  particularly  severe  if  the  overall  look  or 
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placement  of  the  controls  in  the  systems  is  similar,  but  not  identical.  Under  those  conditions, 
operators  expect  to  find  the  controls  in  the  locations  in  which  they  are  found  on  the  first 
system  used.  Unless  the  operator  has  used  the  new  systems  repeatedly  and  frequently,  under 
stressful  conditions  he  or  she  will  revert  to  reacting  as  if  the  controls  are  in  the  expected 
locations  for  the  first  system  used. 

•  Consistency  with  the  decision  maker’s  mental  representation.  The  problem 
representation  within  the  decision  aid  shall  reflect  the  problem  representation,  cognitive 
strategies,  expectations,  and  work  practices  of  the  decision  maker. 

•  Consistent  language/terminology.  Operators  should  not  have  to  wonder  if  different  words, 
situations,  or  actions  mean  the  same  thing.  Small  changes  in  the  language  lead  to  errors  and 
confusion.  Operators  assume  that  different  terms  reflect  differences  in  the  software.  For 
example,  the  term  “Close”  is  expected  to  result  in  a  different  action  than  “Exit”  so  these 
shall  not  be  used  to  label  the  same  action.  Conversely,  if  more  than  one  term  is  used  to 
convey  the  same  concept,  then  the  operator  must  determine  if  the  different  terms  reflect  the 
same  or  a  different  software  activity.  For  example,  an  application  may  incorrectly  use  three 
notations:  “Stop”,  “Cease”,  and  “End”  each  to  mean  that  the  processing  will  not  be 
continued  (e.g.,  identical  terminology  shall  be  used  in  prompts,  menus,  and  help  screens). 

•  Consistent  symbols  and  icons.  Using  more  than  one  icon  design  to  represent  instances  of  a 
single  type  of  control  will  lead  to  errors  and  confusion.  For  example,  using  a  door  icon  and 
an  “X”  symbol  both  to  indicate  “Close”  in  an  application  will  lead  the  operator  to  assume 
that  the  “X”  and  the  door  icon  operate  differently.  Similarly,  differences  in  choices  of  track 
or  symbology  colour  (reversing  the  colour  code  for  Friend  and  Flostile,  for  example)  will 
inevitably  lead  to  errors. 

•  Feedback  consistency.  The  interface  shall  have  a  reliable  and  consistent  method  of  system 
response  across  applications.  Transactions  made  by  the  operator  shall  produce  a  consistent 
perceptual  response  whether  it  is  in  visual,  tactile,  or  auditory  form. 

5.2  Interoperability 

Maritime  CCSs  must  be  seamlessly  interoperable.  Crewmembers  are  expected  to  work  with  many 
C2  systems  over  the  course  of  their  careers.  Differences  in  the  OMI  layouts  of  the  systems,  the 
controls,  navigation,  or  presentation  can  create  delays,  errors,  and  confusion.  Thus  the  overall 
design  should  be  as  consistent  as  possible  with  other  systems  that  the  operator  will  be  using.  This 
recommendation  is  not  intended  to  inhibit  innovative  design  concepts  especially  if  they  overcome 
flaws  or  limitations  in  the  current  systems.  Flowever,  the  introduction  of  new  concepts  should  be 
based  on  proof  that  the  advantage  in  terms  of  reduced  training,  workload  and  more  efficient 
interaction  with  the  system  more  than  offsets  the  requirement  to  learn  a  new  way  of  doing 
business. 

5.3  Usability 

Throughout  this  guide,  the  paramount  goal  is  to  promote  usability.  The  following  heuristics  are 
considered  to  be  basic  requirements  for  complex  operator  interfaces  and,  as  such,  can  be  used  as 
over-arching  recommendations  in  implementing  the  specific  guidelines  provided  in  the  remaining 
sections.  They  have  been  compiled  from  the  source  documents  listed  in  Section  3  as  well  as 
Nielsen  [11]: 
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•  Software  and  equipment  interfaces  shall  provide  a  functional  interface  between  the  system 
for  which  they  are  designed  and  users  (operators/maintainers)  of  that  system.  The  OMI  shall 
optimize  compatibility  with  personnel  and  shall  minimize  conditions  that  can  degrade 
human  performance  or  contribute  to  human  error. 

•  The  system  shall  always  keep  operators  informed  about  what  is  going  on,  through 
appropriate  feedback.  Within  reason,  every  input  by  a  user  shall  consistently  produce  some 
perceptible  response  output  from  the  computer. 

•  The  system  shall  minimize  cognitive  workload  by  maximizing  the  use  of  similar  procedures. 

•  The  system  shall  maximize  the  relevance  of  human-computer  dialogue  to  the  operator’s  job 
and  the  use  of  standard  and  consistent  human-computer  dialogue. 

•  The  system  shall  speak  the  operators’  language,  with  words,  phrases  and  concepts  familiar 
to  the  operator,  rather  than  system-oriented  terms.  Real-world  conventions  shall  be  followed 
to  make  information  appear  in  a  natural  and  logical  order. 

•  Undo  and  redo  functionality  shall  be  supported  where  practical.  Operators  often  choose 
system  functions  by  mistake  and  will  need  a  clearly  marked  “emergency  exit”  to  leave  the 
unwanted  state  without  having  to  go  through  an  extended  dialogue. 

•  The  system  should  minimize  the  frequency  and  significance  of  user  error  and  maximize  the 
ease  of  error  recovery.  When  errors  do  occur,  appropriate  alarms  and  alerts  shall  be 
presented  to  the  operator.  Error  messages  shall  be  expressed  in  plain  language,  precisely 
indicate  the  problem,  and  constructively  suggest  a  solution. 

•  Objects,  actions,  and  options  shall  be  visible  to  the  operator  at  all  times.  The  operator  shall 
not  have  to  remember  information  from  one  part  of  the  dialogue  to  another.  Instructions  for 
use  of  the  system  shall  be  visible  or  easily  retrievable  whenever  appropriate. 

•  The  design  shall  promote  efficiency  of  use  by  minimizing: 

♦  the  necessity  for  the  operator  to  shift  hands  between  the  keyboard  and  other  input 
devices, 

♦  cursor  travel  requirements  across/between  display(s), 

♦  switching  of  visual  focus  between  different  displays  and  windows  during  a 
procedure, 

♦  the  number  of  steps  within  a  procedure,  and 

♦  the  amount  of  window  sizing,  placement  and  manipulations. 

•  The  system  shall  promote  flexibility  of  use  through  the  use  of  accelerators  (e.g.,  hot-keys), 
which  are  unseen  by  the  novice  operator,  to  speed  up  the  interaction  for  the  expert  operator. 
In  this  way,  the  system  can  cater  to  both  inexperienced  and  experienced  operators. 

•  The  sequence  of  transaction  selection  shall  generally  be  dictated  by  user  choices  and  not  by 
internal  computer  processing  constraints.  Operators  shall  also  be  allowed  to  tailor  how  they 
perform  frequent  tasks  (e.g.,  re -configure  windows)  and  shall  be  able  to  manipulate  data 
without  concern  for  internal  storage  and  retrieval  mechanisms  of  the  system. 

•  Even  though  it  is  better  if  the  system  can  be  used  without  documentation,  it  may  be 
necessary  to  provide  help  and  documentation.  Any  such  information  shall  be  easy  to  search, 
be  focused  on  the  operator’s  task,  list  concrete  steps  to  be  carried  out,  and  not  be  too  large. 
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When  the  operators  must  make  similar  decisions,  the  decisions  shall  be  supported  in  the 
OM1  within  the  same  logical  model.  For  example,  models  to  filter  information  can  be 
described  in  two  ways.  One  model  is  described  as  filtering  information  out;  the  other  as 
passing  information  through.  To  avoid  confusion,  the  OM1  must  follow  a  single  model. 
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6  Evaluation  methods  and  measures 


A  unique  component  of  this  Guide  is  the  inclusion  of  recommended  measures  and  methods  for 
evaluating  whether  or  not  the  ESS  and  OMI  are  compliant  with  the  guidelines.  All  projects 
usually  include  some  form  of  quality  assurance.  This  may  involve  systematic  testing  of  the 
individual  components  and  the  overall  system  to  ensure  that  the  hardware  and  software  work  as 
specified.  In  addition,  it  is  becoming  increasingly  important  to  ascertain  that  the  system  can  be 
used  effectively  and  efficiently  by  the  human  operator  in  order  to  achieve  mission  goals.  Thus,  in 
addition  to  providing  guidance  on  the  design  of  the  OMI  and  ESS,  it  is  important  to  provide 
guidance  on  the  evaluation  of  the  system  for  compliance  with  the  guidelines.  Therefore,  the 
Guide  includes  methods  and  measures  for  assessing  the  compliance  of  the  ESS  and  OMI. 

To  assist  the  developer  in  the  evaluation  process,  this  section  provides  a  description  of  the  various 
measures  and  methods  cited  throughout  the  guide  as  well  as  some  specific  tests  for  evaluating 
some  of  the  measures  such  as  situation  awareness  (SA)  and  workload.  The  specification  of  exact 
criteria  to  which  the  components  of  the  OMI  are  evaluated  against  (e.g.,  the  extent  to  which  the 
OMI  affords  adequate  SA  or  workload  levels)  will  depend  on  the  specific  design  and  the  tasks 
and  goals  of  the  operator.  Thus  specific  measures  of  performance  (e.g.,  time  taken  to  hook  a  track 
or  assess  its  threat  level)  will  be  derived  from  a  formal  function  and  task  analysis  including  a 
cognitive  task  analysis. 

As  with  the  evaluation  of  software  and  hardware,  relevant  methodologies  for  evaluating 
compliance  will  vary  across  different  guidelines  and  across  the  development  process.  Typically, 
evaluation  measures  can  be  administered  by  the  following  methodologies: 

•  Inspection:  This  is  usually  carried  out  by  a  person  with  experience  in  the  human  factors  of 
interfaces  to  determine  that  OMI  elements  are  compliant  with  the  guidelines.  It  will  likely 
involve  a  combination  of  review  (e.g.,  number  of  menu  items  that  conform  to  guidelines) 
and  measurement  (e.g.,  visual  angle  of  fonts)  using  a  detailed  check  list  compiled  from  the 
guide. 

•  Demonstration:  This  will  involve  a  walkthrough  of  the  different  system  functions  to  ensure 
they  are  compliant  with  the  guidelines  (e.g.,  pop-up  windows  do  not  obscure  critical  tactical 
information). 

•  Experimentation:  This  will  include  modeling  or  simulation  activities  as  well  as  human-in- 
the-loop  experimental  or  questionnaire -based  studies  to  determine  that  the  system  promotes 
efficient  and  effective  performance  and  is  acceptable  to  the  operator. 

An  overall  framework  for  the  human  factors  evaluation  of  complex  C2  systems  can  be  found  in 
Matthews,  Webb,  and  McCann  [27],  The  developer  should  consult  it  to  determine  when  and  how 
the  various  measures  presented  throughout  the  guide  should  be  used.  For  a  detailed 
experimentation  plan  that  is  consistent  with  this  framework,  the  reader  is  referred  to  the 
INCOMMANDS  Demonstration  and  Experimental  Plan  [28].  For  the  most  part,  the  information 
provided  below  is  adapted  from  that  document. 

6.1  Design  verification 

During  system  development,  construction,  and  acceptance  the  developer  should  subject  the 
emerging  OMI  and  ESS  designs  to  verification  checks  that  relevant  human  factors  requirements, 
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methods,  and  guidelines  are  being  followed.  Verification  addresses  the  question:  “ Did  the 
developers  do  the  right  things?”  Verification  tends  to  be  a  checklist  and  review  approach 
conducted  by  external  independent  specialists.  Verification  techniques  include  expert  reviews  of 

•  human  factors  program  plans  and  scheduling, 

•  methods  employed  for  various  human  factors  activities  (e.g.,  task  analysis), 

•  suitability  and  application  of  feature  related  guidelines  (i.e.,  compliance  with  this  guide), 
and 

•  compliance  with  the  design  guidance  outlined  in  Section  5. 

Verification  is  usually  done  using  a  combination  of  inspection  and  demonstration  methodologies. 

6.2  System-based  measures 

System-based  measures  assess  the  capabilities  of  the  total  system  (i.e.,  operator  and  machine). 
The  following  measures  are  illustrative  of  system-based  measures  of  performance: 

•  Time  to  detect  targets,  taken  from  the  time  the  target  was  available  for  detection  by  the 
system’s  sensors  to  the  time  of  actual  threat  determination; 

•  Percentage  of  targets  detected,  through  a  comparison  of  system-determined  targets  versus 
ground  truth  in  any  experimental  situation; 

•  Percentage  of  targets  recognized/identified,  through  a  comparison  of  the  identification  of 
detected  targets  versus  ground  truth  in  any  experimental  situation;  and, 

•  Accuracy  of  target  location  of  all  target  detection/recognition/identification,  through  a 
comparison  of  reported  positions  versus  ground  truth. 

The  collection  of  system-based  measures  requires  at  least  a  working  prototype  of  an  operational 
system.  Thus,  a  demonstration  methodology  is  used. 

6.3  Operator-based  measures 

Unlike  system-based  measures,  operator-based  measures  assume  that  hardware  and  software  are 
working  optimally.  They  assess  how  well  the  OMI  and  ESS  support  the  operator  in  carrying  out 
tasks  effectively  and  efficiently,  provide  good  SA  and  optimal  workload,  and  engender 
appropriate  level  of  trust  in  the  capabilities  of  the  system.  For  a  more  detailed  discussion  of 
operator-based  methods  see  Hollands  [29]  and  Pina,  Donmez  and  Cummings  [30]. 

Since  all  operator-based  measures  must  take  into  account  individual  differences,  some  form  of 
experimental  methodology  is  required. 

6.3.1  Operator  performance 

Operator  performance  measures  assess  how  easy  it  is  for  an  operator  to  use  the  various 
components  of  the  interface  and  ESS  to  carry  out  his  or  her  tasks  and  how  useful  the  available 
features  and  function. 
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6.3. 1.1  Speed  of  task  completion 


Measurement  of  task  performance  speed  can  be  used  to  provide  an  objective  measure  of  operator 
performance  for  pre-defmed  sequences  of  events  (e.g.,  time  taken  to  detect  target,  time  taken  to 
identify  target,  time  taken  to  apply  combat  power).  Determination  of  task  performance  speed  can 
be  measured  manually  by  means  of  a  stopwatch  during  real  time  or  later  by  means  of  video 
analysis.  Task  performance  speed  can  also  be  determined  automatically  through  the  insertion  of  a 
marker  in  the  prototype  evaluation  software  to  mark  pre-defmed  task  start  times. 

6.3.1 .2  Accuracy  of  task  performance 

Measurement  of  task  performance  accuracy  can  be  used  to  provide  an  objective  measure  of 
operator  performance  of  pre-defmed  sequences  of  events  (e.g.,  correct  target  identification, 
correct  ranking  of  threat  priority,  correct  application  of  combat  power).  Determination  of  task 
performance  accuracy  can  be  measured  by  comparing  test  participant  performance  and  output 
against  pre-determined  performance  criteria.  However,  the  interpretation  of  such  data  can  be 
difficult.  For  a  more  complete  discussion  of  accuracy  assessment  see  Hollands  [29]. 

6.3.2  Operator  decision  making  quality 

One  difficulty  with  conducting  research  on  operator  decision  making  is  deciding  how 
performance  is  defined.  Research  to-date  has  been  dominated  by  assessing  the  quality  of  a 
decision  by  quantifying  the  value  of  the  outcome  for  a  given  event.  In  many  instances,  this  will  be 
a  binary  output  in  terms  of  a  simple  correct  or  incorrect  outcome.  Unfortunately,  such  a  measure 
reveals  little  of  the  decision  processes  involved  in  arriving  at  a  course  of  action.  Thus,  it  is 
important  to  consider  decision  making  in  the  context  of  “process”  (i.e.,  how  a  decision  was 
reached)  as  well  as  “outcome”  (i.e.,  what  decision  was  reached).  Potential  metrics  for  assessing 
decision  making  quality  are  discussed  below.  Currently,  most  of  these  can  only  be  assessed 
through  direct  observation  of  operator  performance,  protocol  analysis,  or  probes  during  scenarios 
designed  to  elicit  the  desired  behaviours  [29]. 

6.3.2. 1  Situation  assessment 

Inherent  in  the  “recognition-primed”  accounts  of  decision  making  is  the  notion  of  pattern- 
matching  the  mental  representation  of  the  situation  with  past  experience.  Clearly,  the  quality  of 
decision  making  is  related  to  the  quality  of  this  mental  representation  of  the  situation,  which  in 
turn  is  related  to  the  quality  of  the  processes  undertaken  to  acquire  it.  Thus,  one  way  of  assessing 
decision  quality  is  to  assess  the  quality  of  the  situation  assessment  processes  underlying  the 
formation  of  the  decision  (see  Clark,  Banbury,  Richards  and  Dickson  [31]). 

Banbury,  Dudfield,  Hoermann  and  Soil  [32]  developed  a  questionnaire-based  measure  to  assess 
the  efficacy  of  the  situation  assessment  processes.  The  Factors  Affecting  Situation  Awareness 
(FAS A)  questionnaire  comprises  30  questions,  divided  into  the  following  five  sub-scales: 
Attention  Management  (participants’  ability  to  attend  to  more  than  one  task  at  a  time  and  resume 
a  task  successfully  after  being  interrupted);  Information  Management  (participants’  motivation  to 
acquire  appropriate  information  to  make  rational  decisions);  Cognitive  Efficiency  (participants’ 
ability  to  ignore  distractions  and  maintain  SA  despite  external  stressors);  Automaticity 
(participants’  experience  performing  routine  tasks  in  a  highly  practiced,  automatic  way),  and 
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Inter-Personal  Dynamics  (participants’  knowledge  of  non-verbal  communication  and  their  views 
on  what  team  membership  entails). 

6.3. 2. 2  Timeliness  and  agility 

With  the  nature  of  modem  warfare  relying  heavily  on  information  quality  and  supremacy,  it  has 
become  crucial  that  operators  quickly  adapt  to  the  changing  context  within  which  they  may  find 
themselves.  The  speed  of  decision  making  can  be  couched  in  temis  of  decision  “timeliness”  (e.g., 
a  change  of  strategy  at  the  appropriate  time)  and  decision  “agility”  (e.g.,  adaptability  to  changing 
circumstances).  The  ability  to  evaluate  timeliness  and  agility  will  depend  on  the  scenarios  used. 

6.3. 2. 3  Consistency 

The  consistency  of  decision  making  is  a  useful  insight  into  decision  making  quality,  as  it  can  be 
argued  that  differences  of  outcome  from  decisions  based  on  the  same  data  could  indicate 
inappropriate  or  incorrect  reasoning  processes.  Arguably,  operators  who  have  made  accurate 
situation  assessments  and  correct  inferences  based  on  these  data,  should  reach  the  same  outcome 
each  and  every  time  a  similar  decision  is  made. 

6.3. 2. 4  Justifiability  and  rationality 

Justifiability  and  rationality  complement  the  accuracy  measure  of  decision  making  quality  by 
providing  insight  into  the  underlying  processes  that  led  the  operator  to  make  a  decision. 
Specifically,  operators  that  make  an  inaccurate  decision  may  be  able  to  fully  justify  their  choice 
by  providing  the  rationale  behind  their  decision.  The  quality  of  this  decision  is  therefore  good, 
despite  its  seemingly  inaccurate  outcome.  Further,  an  accurate  decision  is  not  necessarily  a  good 
one  given  that  it  could  have  been  made  by  chance  alone  (i.e.,  the  operator  guessed  right).  If  the 
operator  was  asked  why  this  decision  was  made,  he/she  would  not  be  able  to  justify  it  or  provide  a 
corresponding  rationale.  In  both  cases,  accuracy  would  provide  an  incomplete  and  misleading 
metric  of  decision  quality. 

6.3.3  Operator  situation  awareness 

SA  is  a  key  determinant  of  task  performance  and  relates  to  the  ability  of  the  operator  to  maintain 
awareness  of  task-relevant  objects  in  his/her  immediate  environment.  The  measurement  of  SA 
within  the  context  of  the  INCOMMANDS  TDP  is  important  given  the  emphasis  placed  on 
automation-based  technologies.  On  one  hand,  these  technologies  might  afford  the  operator  more 
information  than  they  might  otherwise  have  access  to  resulting  in  higher  levels  of  operator  SA. 
On  the  other  hand,  it  is  possible  that  too  much  reliance  on  these  automation  technologies  might 
have  a  negative  impact  of  operator’s  SA  because  the  operator  is  consigned  to  monitoring  the 
automation,  and  not  fully  engaged  in  the  task.  Several  different  methods  have  been  developed 
(see  Breton,  Tremblay,  and  Banbury  for  a  discussion  [33]).  Two  of  the  better  know  methods  are 
discussed  below. 

6.3. 3.1  Situation  Awareness  Global  Assessment  Technique  (SAGAT) 

The  Situation  Awareness  Global  Assessment  Technique  (SAGAT)  [34,  35]  is  an  objective 
measure  of  situation  awareness.  It  employs  periodic,  randomly  timed  freezes  in  a  simulation 
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scenario  during  which  all  of  the  operators  displays  are  temporarily  blanked.  At  the  time  of  the 
freeze  a  series  of  queries  are  provided  to  the  operator  to  assess  his  or  her  knowledge  of  what  was 
happening  at  the  time  of  the  freeze.  The  queries  typically  cover  three  SA  levels: 

•  Perception  (i.e.,  noticing  all  of  the  relevant  entities  in  the  environment), 

•  Comprehension  (i.e.,  understanding  their  meaning),  and 

•  Projection  (i.e.,  anticipating  their  future  states). 

Queries  are  determined  based  on  an  in-depth  cognitive  task  analysis  that  must  be  conducted  for 
each  domain  that  SAGAT  is  used  in.  The  questions  are  typically  a  random  subset  of  a  larger 
standard  set  of  questions  that  are  relevant  to  the  training  scenario.  Operator’s  responses  to  these 
queries  are  scored  based  on  what  was  actually  happening  in  the  simulation  at  the  time  of  each 
freeze. 

The  main  advantage  of  SAGAT  is  that  it  allows  an  objective  unbiased  index  of  SA  that  assesses 
operator  SA  across  a  wide  range  of  elements  that  are  important  in  a  particular  system.  The  main 
disadvantage  of  SAGAT  is  that  it  requires  freezes  in  the  simulation,  and  as  a  result,  this  measure 
can  only  be  used  for  laboratory  evaluations.  Because  the  freezes  are  random  and  cover  a  broad 
spectrum  of  operator  SA  requirements,  operators  cannot  prepare  for  the  queries.  Moreover,  it  has 
been  found  that  the  freezes  do  not  affect  performance  in  the  simulations. 

An  alternative  SAGAT  approach  is  to  measure  the  amount  of  time  it  takes  operators  to  report 
anomalies  embedded  into  the  scenario,  then  note  the  time  it  takes  them  to  deviate  from  the 
original  plan,  given  the  change  in  circumstances. 

SAGAT  can  also  provide  insight  into  crew  performance  within  simulated  team  environments  as 
well  as  individual  performance.  Queries  can  be  designed  to  assess  specific  SA  requirements  for 
each  team  member  role.  More  importantly,  responses  to  queries  related  to  common  SA 
requirements  can  be  compared  across  team  members.  In  addition,  specific  responses  can  be 
compared  to  determine  whether  the  same  responses  (correct  or  incorrect)  are  made  across  team 
member  roles.  This  type  of  analysis  can  provide  diagnostic  information  regarding  the  source  of 
breakdowns  in  team  SA.  For  example,  common  incorrect  responses  may  indicate  problems  that 
affect  the  entire  team  (such  as  poorly  designed  information  display).  Alternatively,  a  mix  of 
correct  and  incorrect  responses  or  different  incorrect  responses  across  team  member  roles  may 
indicate  a  breakdown  in  team  coordination. 

6. 3. 3. 2  Situation  Awareness  Rating  Technique  (SART) 

The  Situation  Awareness  Rating  Technique  (SART)  [36,  37]  provides  a  validated  and  practical 
subjective  rating  tool  for  the  measurement  of  SA,  based  on  personal  construct  dimensions 
associated  with  SA.  The  structure  of  the  construct  dimensions  has  been  interpreted  as  comprising 
of  three  related  conceptual  groups,  which  form  the  principal  dimensions  of  SART,  namely: 

•  Demand  for  attentional  resources  or  D  (complexity,  variability,  instability); 

•  Supply  of  attentional  resources  or  S  (arousal,  concentration,  division  of  attention,  spare 
mental  capacity); 

•  Understanding  of  the  situation  or  U  (information  quality,  information  quantity,  familiarity). 
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The  most  commonly-used  version  of  SART  is  the  14-dimension  version.  Instead  of  numeric 
Likert-scales,  a  graphical  display  of  the  rating  scales  is  utilized,  where  the  length  of  a  line  from 
the  left  hand  side  of  the  scale  to  the  participant’s  mark  (in  millimetres)  represents  a  respective 
rating  score  for  one  item.  The  possible  range  is  between  0  (low)  and  50  (high). 

Questions  1,  2,  3  and  4  are  averaged  to  give  a  D  score  (Demand).  Questions  5,  6,  7,  8  and  9  are 
averaged  to  give  an  S  score  (Supply).  Questions  10,  11,  12  and  13  are  averaged  to  give  a  U  score 
(Understanding).  SA  in  total  (T)  is  then  calculated  by  U  -  (D  -  S).  Finally,  Question  14  gives  the 
participant’s  confidence  in  their  ratings  of  the  above. 

6.3.4  Operator  workload 

Another  key  determinant  of  task  performance  is  the  workload  experienced  by  the  operator  when 
engaging  in  tasks.  It  can  be  conceptualised  in  terms  of  both  physical  and  mental  effort.  The 
following  section  describes  a  well-validated  measure  of  workload. 

6.3. 4.1  National  Aeronautics  and  Space  Administration  -  Task  Load  Index 

The  National  Aeronautics  and  Space  Administration  -  Task  Load  Index  (NASA-TLX)  [38] 
allows  operators  to  perform  subjective  workload  assessments  when  working  with  various  human- 
machine  systems.  It  is  a  multi-dimensional  rating  procedure  that  derives  an  overall  workload 
score  based  on  a  weighted  average  of  ratings  on  six  subscales.  These  subscales  include 

•  mental  demands, 

•  physical  demands, 

•  temporal  demands, 

•  own  performance, 

•  effort,  and 

•  frustration. 

The  degree  to  which  each  of  the  six  factors  contribute  to  the  workload  of  the  specific  task  to  be 
evaluated,  from  the  operator’s  perspective,  is  determined  by  their  responses  to  pair-wise 
comparisons  among  the  six  factors.  Magnitude  ratings  on  each  subscale  are  obtained  after  each 
performance  of  a  task  or  task  segment.  Ratings  of  factors  deemed  most  important  in  creating  the 
workload  of  a  task  are  given  more  weight  in  computing  the  overall  workload  score,  thereby 
enhancing  the  sensitivity  of  the  scale. 

The  simple  nature  of  the  scale  permits  subjects  to  provide  ratings  quickly  in  any  operational 
settings.  The  scale  can  be  administered  using  paper  or  via  a  direct  operator  input  program,  in  real¬ 
time  or  retrospectively.  It  has  been  demonstrated  that  little  information  is  lost  when  ratings  are 
given  retrospectively.  The  NASA-TLX  has  been  tested  in  a  variety  of  experimental  tasks  that 
range  from  simulated  flight  to  supervisory  control  simulations  and  laboratory  tasks  (e.g.,  choice 
reaction  time,  critical  instability  tracking,  compensatory  tracking,  mental  arithmetic,  mental 
rotation,  target  acquisition,  grammatical  reasoning).  It  can  be  used  to  assess  workload  in  various 
human-machine  environments  such  as  aircraft  cockpits,  C2  workstations,  supervisory  and  process 
control  environments,  simulations,  and  laboratory  tests. 
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6.3.5  Operator  fatigue 


Operator  performance,  as  well  as  general  acceptance  of  the  system,  will  be  significantly  affected 
by  operational  fatigue.  It  is  therefore  important  to  consider  the  effects  of  operator  fatigue  on  the 
system  in  order  to  avoid  negative  outcomes  due  to  fatigue-induced  errors  (e.g.,  when  monitoring 
an  automated  system  over  extended  periods  of  time).  A  fatigue  rating  questionnaire  such  as  the 
Karolinska  Sleepiness  Scale  [39]  provides  a  simple  subjective  self  report  measure  of  fatigue  that 
can  be  administered  at  the  same  time  as  other  system  performance  or  acceptance  measures. 

6.3.6  Operator  acceptance 

The  Technology  Acceptance  Model  (TAM)  [40]  is  an  information  systems  theory  that  models 
how  operators  come  to  accept  and  use  a  technology.  The  model  suggests  that  when  operators  are 
presented  with  a  system,  several  factors  will  influence  their  decision  about  how  and  when  they 
will  use  it,  notably: 

•  Perceived  Usefulness:  This  is  defined  as  “the  degree  to  which  a  person  believes  that  using  a 
particular  system  would  enhance  his  or  her  job  performance.” 

•  Perceived  Ease-of-Use:  This  is  defined  as  “the  degree  to  which  a  person  believes  that  using 
a  particular  system  would  be  free  from  effort.” 

The  TAM  utilizes  a  questionnaire  that  has  been  assessed  for  robustness  across  populations  and 
predictive  validity  [40].  Studies  have  found  high  reliability  and  good  test-retest  reliability  and  that 
the  instrument  had  predictive  validity  for  intent  to  use,  self-reported  usage  and  attitude  toward 
use.  The  sum  of  this  research  has  confirmed  the  validity  of  the  instrument,  and  supports  its  use 
with  different  populations  of  operators  and  different  software  choices. 

6.3.7  Assessments  of  system  usability  and  usefulness 

A  questionnaire  relating  to  the  high-level  usability  aspects  of  the  OMI  (e.g.,  suitability  of  screen 
windows,  keyboard  and  joystick)  can  be  used  to  assess  operator  perceptions  of  system  usability. 
Typically,  ratings  are  based  on  a  five-point  Likert  scale;  ranging  from  1:  Strongly  Disagree  to  5: 
Strongly  Agree.  A  similar  questionnaire  relating  to  the  perceived  utility  of  the  workstation 
functions  and  capabilities  (e.g.,  drill-down)  can  be  used  to  assess  operator  perceptions  of  system 
usefulness.  The  content  of  the  questionnaire  will  be  tailored  to  the  interface.  Examples  of  a 
usability  and  a  utility  question  are  shown  in  Figure  1.  For  detailed  guidance  on  the  design  of 
usability  and  usefulness  questionnaires,  the  reader  is  referred  to  Engel  and  Townsend  [41]. 
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Figure  1:  Examples  of  questions  to  assess  the  usability  (top)  and  utility  (bottom)  of  an  OMI 


6.3.8  Operator  trust 

In  the  context  of  an  ESS,  trust  can  be  defined  as  the  extent  to  which  an  operator  is  confident  in 
and  willing  to  act  on  the  basis  of  the  recommendations,  actions,  and  decisions  of  the  ESS  [42]. 
However,  trust  is  not  a  simple  uni-dimensional  variable.  It  is  possible  to  correctly  distrust  a 
system  (e.g.,  when  it  is  unreliable),  but  also  to  be  too  trusting  (over-trusting  or  complacent)  or  not 
trusting  enough  (under-trusting  or  sceptical). 

Considerable  research  has  been  carried  out  on  operator  trust  and  acceptance  of  automation.  Most 
of  this  research  involves  an  indirect  assessment  of  trust  based  on  the  extent  to  which  an  operator 
uses  an  ESS  system  as  a  function  of  its  reliability  [43-45].  However,  only  a  small  number  of  tools 
have  been  developed  and  evaluated  to  assess  trust  directly  [30],  One  such  tool  is  the  human- 
computer  trust  scale  developed  by  Madsen  and  Gregor  [42].  With  their  rating  scale,  overall  trust 
in  the  decision  aid  is  determined  by  cognition-based  trust  (i.e.,  trust  relating  to  the  operator’s 
perception  of  the  automation)  and  affect-based  trust  (i.e.,  trust  relating  to  the  operator’s  emotive 
response  to  automation).  Three  factors  underpin  cognition-based  trust  (i.e.,  perceived 
understandability,  technical  competence,  and  reliability  [of  the  system]),  and  two  factors  underpin 
affect-based  trust  (i.e.,  faith  [in  the  system]  and  personal  attachment  [to  the  system]).  Although 
Madsen  and  Gregory  evaluated  the  reliability  and  validity  of  this  tool,  it  is  not  clear  how  widely  it 
is  used.  See  Pina  [30]  for  other  rating  scales  for  measuring  human-computer  trust. 
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7  ESS  OMI  design  guidelines 


7.1  General  design  goals 

7.1.1  Employ  operator  centered  principles 

1.  The  ESS  shall  be  used  to  support  the  operator(s)  where  appropriate  (e.g.,  human-centered 
ESS),  not  implemented  simply  because  the  technology  is  available  (e.g.,  technology- 
centered  ESS). 

2.  The  ESS  shall  be  designed  to  match  the  operator’s  mental  model  of  the  domain  as  well  as 
the  processes  underlying  system  operation. 

3.  The  ESS  shall  help  or  enable  the  operators  to  carry  out  their  responsibilities  and  tasks 
safely,  efficiently,  and  effectively.  [Carrying  out  a  task  effectively  means  producing  the 
desired  result.  Carrying  out  a  task  efficiently  means  that  the  desired  result  is  produced 
with  a  minimum  of  waste  (usually  in  relation  to  time)]. 

4.  The  operator  shall  always  have  final  authority  over  the  allocation  of  ESS  functions  (i.e., 
task  allocated  to  human  and/or  system). 

5.  Functions  shall  be  automated  only  to  attain  greater  overall  effectiveness,  efficiency, 
reliability,  simplicity,  economy,  and  system  safety  without  reducing  human  involvement, 
situation  awareness,  or  human  performance  in  carrying  out  the  intended  task. 

6.  The  relationships  between  display,  control,  decision  aid,  and  information  structure  and 
operator  tasks  and  functions  shall  be  clear  to  the  operator. 


Source 

HFDS,  SheridanOO,  DEFSTD25,  AHC1,  D1SA,  MS1472F,  Endsley99. 

Discussion 

G2.  The  operator  must  interpret  the  information  provided  to  him/her.  The  operator’s  training, 
experience,  biases  will  influence  the  quality  of  the  decision  and  execution  of  their  task  (s). 

G4.  The  reasoning  behind  this  guideline  is  twofold.  First,  it  is  ultimately  the  operator  who  is 
responsible  for  the  task.  Second,  ESS  automation  is  subject  to  failure.  Therefore,  it  is  the 
operator,  not  the  automation,  who  must  be  in  authority  of  the  system  with  the  automation  playing 
a  subservient  role. 

G5.  Automation  can  lead  to  distraction  from  the  primary  task,  increased  workload,  boredom 
or  complacency. 

G6.  The  operator  needs  to  be  able  to  see  clearly  how  the  display  or  decision  aid,  and  so  on, 
facilitates  the  completion  of  the  necessary  task 


Evaluation  methods  and  measures 
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Design  verification: 

•  Analysis  and  design  methodology  are  compliant  with  MIL-HDBK-46855A  (Human 
Engineering  Program  Process  and  Procedures)  [26]. 

•  Verification  of  the  adequacy  of  system  usability  and  utility  in  terms  of  its  design. 

Operator  performance: 

•  Objective  measure  of  the  adequacy  of  OMI  usability. 

Operator  acceptance: 

•  Subjective  assessments  of  the  adequacy  of  operator’s  perceptions  of  system  usability  and 
utility. 

Relationship  to  other  guidelines 

7.1.2  Optimize  human-system  interaction 

7.2  Employ  operator-centered  OMI  design 

8.2.3  Keep  operators  in  control 

23.1  Adopt  operator-centered  design  principles 

7.1.2  Optimize  human-system  interaction 

1.  The  ESS  shall  provide  sufficient  information  to  keep  the  operator  informed  of  its 
operating  mode,  intent,  function,  and  output;  inform  the  operator  of  system  failure  or 
degradation;  inform  the  operator  if  potentially  unsafe  modes  are  manually  selected;  not 
interfere  with  manual  task  performance;  and  allow  for  manual  override. 

2.  ESS  system  functioning  shall  be  transparent  to  the  operator  at  all  times. 

3.  The  operator  shall  have  active  involvement  in  the  operation  of  the  ESS.  Operators  shall 
be  given  an  active  role  through  relevant  and  meaningful  tasks  in  the  operation  of  a 
system,  including  when  the  tasks  are  automated. 

4.  ESS  functionality  shall  be  appropriate  to  the  operator’s  level  of  expertise  with  the  system 
(e.g.,  shortcuts  such  as  function  keys  can  be  provided  for  the  more  experienced 
operators). 

5.  ESS  functioning  shall  not  increase  the  demands  for  cognitive  resources  (thinking  or 
conscious  mental  processes). 

6.  Extreme  levels  of  workload  (low  or  high)  due  to  ESS  functioning  shall  be  avoided  (to 
maximize  operator-in-the-loop  and  reduce  automation  bias). 

7.  Operator  interaction  with  the  ESS  shall  not  require  the  operator  to  take  significant 
amounts  of  attention  away  from  the  primary  task. 
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8.  The  ESS  shall  not  interrupt  at  inappropriate  times  such  as  during  periods  of  high 
workload  or  during  critical  moments  in  a  process. 

9.  An  ESS  task  shall  be  less  difficult  to  carry  out  than  the  manual  task  it  replaces. 

10.  Data  that  are  needed  by  the  operator  shall  be  easily  accessible. 

11.  The  ESS  shall  allow  the  operator  to  interact  directly  with  objects  which  are  important  to 
the  operator’s  tasks. 


Source 

HFDS,  D1SA,  Parasuraman97,  AHC1,  MS1472F,  Endsley96,  DEFSTD25,  Endsley99. 

Discussion 

G2.  The  transparency  of  system  functioning  (i.e.,  the  properties  of  the  ESS  which  allow  the 
operator  to  understand  its  actions)  will  increase  the  predictability  of  the  ESS  (e.g.,  reliability  of 
automatically  detecting  and  prioritizing  tracks)  by  ensuring  the  operator  is  cognisant  of  the 
limitations  of  the  ESS.  In  addition,  it  is  very  important  that  operators  understand  why,  and  under 
what  conditions,  the  ESS  might  make  errors.  Trust  should  increase  if  operators  receive 
informative  feedback  in  the  event  of  an  ESS  error  (e.g.,  explanation  of  system  error).  For  general 
information  on  providing  feedback  to  the  operator,  see  M1L-STD  1472F  [9]. 

G3.  Operator  awareness  of  ESS  state  can  not  be  sustained  passively.  Active  involvement  is 
essential  for  operators  to  exercise  their  responsibilities  and  be  able  to  respond  to  emergencies. 
Reducing  active  involvement  may  be  detrimental  to  the  operator’s  understanding  of  important 
information,  may  lead  to  longer  response  times  in  case  of  emergencies,  or,  in  the  long  term,  may 
lead  to  loss  of  relevant  knowledge  or  skills. 

G4.  ESS  functions  that  increase  the  demand  for  cognitive  resources  of  the  operator  is  an 
artefact  of  poor  design.  Expert  operators  in  complex,  dynamic  systems  have  been  observed  to 
cope  with  a  poorly  designed  ESS  by  using  only  a  subset  of  the  available  functionality,  especially 
during  periods  of  high  workload. 

G6.  An  ESS  can  cause  extreme  workload  levels  by  increasing  workload  when  it  is  already 
high  and  decreasing  workloads  that  are  already  low.  AN  ESS  is  often  introduced  to  reduce 
workload.  Flowever,  reduction  of  workload  may  not  always  be  advantageous,  for  example,  if 
workload  is  already  low. 

G7.  When  an  ESS  requires  the  operator  to  devote  a  significant  amount  of  attention  to 
adjusting  or  monitoring  the  ESS  functioning,  this  removes  the  operator  away  from  minute-to- 
minute  operations,  thereby  taking  the  operator  out  of  the  loop.  This  can  be  especially  dangerous  if 
an  abnormal  situation  occurs  that  needs  to  be  remedied  quickly. 

G8.  An  interruption  during  high  workload  or  at  a  critical  moment  can  cause  a  delay  in  the 
operator’s  ability  to  respond  to  an  ESS  malfunction,  leading  to  a  potential  failure.  If  the  operator 
is  attending  to  an  ESS  malfunction  and  is  interrupted,  the  interruption  depletes  the  operator’s 
mental  resources  causing  him  to  be  less  capable  of  averting  the  potential  failure. 
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G10.  Operator  requirements  can  serve  as  a  guide  to  whether  the  data  are  available  at  all  times, 
accessible  at  the  operators’  discretion,  or  not  at  all  if  the  operator  does  not  need  information. 

Evaluation  methods  and  measures 

Design  verification: 

•  Analysis  and  design  methodology  are  compliant  with  MIL-HDBK-46855A  (Human 
Engineering  Program  Process  and  Procedures)  [26]. 

•  Verification  of  the  adequacy  of  system  usability  and  utility  (in  terms  of  its  design). 

Operator  performance: 

•  Objective  measures  of  the  adequacy  of  OMI  ease  of  use  and  usefulness  through  usability 
testing. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  situation  awareness  of  ESS 
functioning. 

•  Subjective  and  objective  (e.g.,  performance,  errors)  assessment  of  the  adequacy  of  the 
operator’s  understanding  of  the  limitations  of  the  ESS. 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  situation  awareness  of  task-relevant 
objects  in  the  environment. 

Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  workload. 

Relationship  to  other  guidelines 

7.1.1  Employ  operator  centered  principles 

8.2.4  Maximize  operator  situation  awareness  by  increasing  system  transparency 

8.3.1  Keep  operators  “in-the-loop” 

7.1.3  Promote  ESS  robustness  and  resilience  to  operator  error 

1.  The  ESS  shall  be  resistant  to  operator  error  while  tolerating  some  reasonable  level  of 
“error”  and  response  variability. 

2.  The  ESS  shall  be  able  to  monitor  operator  interactions  and  to  warn  of  operator  errors. 

3.  ESS  functions  shall  be  capable  of  being  overridden  by  the  operator  in  an  emergency.  ESS 
functioning  shall  not  be  difficult  or  time  consuming  to  turn  on  or  off. 

4.  Operators  shall  not  be  too  reliant  on  ESS  functioning  to  the  extent  that  their  skills  are 
degraded  by  extended  use  of  the  ESS  and  that  they  can  no  longer  safely  recover  from 
emergencies  or  operate  the  ESS  manually  if  the  ESS  fails. 
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5.  ESS  shall  not  be  able  to  veto  operator  actions  leaving  the  operator  without  means  to 
override  or  violate  the  rules  that  govern  the  ESS  unless  there  is  not  enough  time  for  the 
operator  to  make  a  decision. 

6.  ESS  interactivity  (i.e.,  navigation,  functionality,  features,  information  structure)  shall  be 
consistent  within  and  between  systems. 

7.  ESS  status  during  system  setup  shall  be  transparent  to  the  operator  (e.g.,  system  failure 
due  to  system  setup  or  manual  input  of  information). 

8.  Allocation  of  tasks  shall  be  flexible  and  adaptable  (e.g.,  a  task  allocated  to  an  ESS  or  an 
operator  can  be  adapted  according  to  the  context)  and  the  operator  shall  always  have 
authority  over  how  the  tasks  are  allocated. 

9.  The  ESS  shall  make  it  clear  whether  the  operator  or  the  ESS  is  supposed  to  perform  a 
particular  task  at  a  specific  time. 

10.  The  allocation  of  tasks  related  to  decision/action  to  the  ESS  shall  be  under  the  authority 
of  the  operator,  particularly  under  situations  of  greater  uncertainty  and  risk. 

1 1.  To  increase  operator  trust  in  the  ESS,  ESS  performance  shall  be:  reliable  and  predictable 
with  minimal  errors;  robust  (able  to  perform  under  a  variety  of  circumstances);  familiar 
(uses  terms  and  procedures  familiar  to  the  operator);  and,  useful. 

12.  The  ESS  shall  be  available  to  the  operator  as  needed. 

13.  The  ESS  shall  not  interfere  with  task  performance. 

14.  The  ESS  shall  provide  accurate  and  reliable  information. 

Source 

HFDS,  MS1472F,  D1SA,  SheridanOO,  AHCI,  Parasuraman97,  DEFSTD25. 
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Discussion 


Gl.  To  make  a  system  error  resistant  is  to  make  it  difficult  for  an  operator  to  make  an  error. 
Simplicity  in  design  and  the  provision  of  clear  information  are  tools  to  improve  error  resistance. 
Electronic  checklists  also  have  the  potential  to  improve  error  resistance  by  providing  reminders  of 
items  that  need  to  be  completed.  Error  tolerance  is  the  ability  to  mitigate  the  effects  of  human 
errors  that  are  committed.  Error  tolerance  can  be  improved  by  adding  monitoring  capabilities  to 
the  ESS.  Acceptable  levels  of  error  and  response  variability  enhance  learning  (of  the  operator). 

G4.  A  balance  is  needed  between  the  efficiency  created  by  the  ESS,  and  the  need  for  the 
operator  to  be  able  to  recover  from  emergencies  and  control  the  ESS  manually  in  case  the  ESS 
fails. 

G5.  The  resumption  of  manual  control  needs  to  be  within  the  capacity  of  the  operator,  without 
relying  on  manual  skills. 

G6.  There  are  many  possible  types  of  interaction,  such  as  menu  selection,  direct  manipulation, 
and  form-filling.  An  example  of  inconsistent  interaction  would  be  having  one  ESS  require  filling 
in  forms  as  the  interaction  method,  whereas  another  ESS  requires  menu-driven  interaction. 
However,  in  the  case  of  repetitive  movement  using  a  single  input  device  (e.g.,  track-ball), 
operator  fatigue  can  be  mitigated  by  using  an  alternative  method  of  interaction  (e.g.,  touch  screen 
in  addition  to  the  track-ball). 

G7.  ESS  failures  are  often  due  to  setup  error.  Although  the  ESS  itself  could  check  some  of  the 
setup,  independent  error-checking  equipment  or  procedures  may  be  needed.  The  operator  needs  to 
be  able  to  distinguish  whether  a  failure  occurred  due  to  the  ESS  setup  or  due  to  an  inaccuracy  in 
the  input  information.  A  failure  could  have  been  caused  by  a  malfunction  of  an  algorithm  or  by 
the  input  of  inaccurate  data.  ESS  operations  that  are  easily  interpretable  or  understandable  by  the 
operator  can  facilitate  the  detection  of  improper  operation  and  the  diagnosis  of  malfunctions. 

G8.  Problems  with  an  ESS  can  occur  when  ESS-generated  options  do  not  apply  to  a  situation 
and  the  operator  is  restricted  to  the  options  provided  by  the  ESS. 

G10.  High  levels  of  ESS  automation  (i.e.,  the  ESS  initiates  and  performs  the  task)  can  be  used 
for  tasks  involving  relatively  little  uncertainty  and  risk.  Since  the  decision  as  to  whether  or  not  a 
situation  is  one  of  greater  uncertainty  and  risk  will  be  made  by  the  operator,  allocation  should 
always  be  under  control  of  the  operator. 

Gil.  Trust  in  automation  tends  to  be  relatively  stable.  However,  changes  in  trust  may  occur 
over  time.  Operator  trust  in  automation  can  increase  with  reliable  and  predictable  performance. 
Decreases  in  trust  may  occur  as  a  result  of  some  critical  error  or  automation  failure.  It  is  more 
difficult  for  operators  to  regain  trust  in  automation  after  a  failure  than  to  develop  an  initial  trust. 
Higher  trust  in  automation  is  not  always  better  because  automation  errors  may  be  overlooked  due 
to  complacency.  Decreases  in  trust  typically  occur  suddenly,  but  increases  happen  slowly  and 
steadily.  The  consequences  of  an  automation  failure  (e.g.,  the  magnitude  of  an  error)  impact  the 
decline  in  trust. 

G13.  An  operator  will  be  less  likely  to  accept  an  automated  system  that  interferes  with  their 
ability  to  perform  tasks. 
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G14.  When  operators  believe  the  system  to  be  highly  reliable,  they  place  greater  trust  in  it. 
However,  there  is  a  trade-off  involved  with  a  constant  high  level  of  automation  reliability  and 
predictability.  Constant  high  levels  of  reliability  and  predictability  may  be  more  likely  to  promote 
complacency  and  may  cause  operators  to  monitor  the  system  with  less  vigilance. 

Evaluation  methods  and  measures 

Design  verification: 

•  Analysis  and  design  methodology  are  compliant  with  MIL-HDBK-46855A  (Human 
Engineering  Program  Process  and  Procedures)  [26]. 

•  Verification  of  the  adequacy  of  system  usability  and  utility  (in  terms  of  its  design). 

Operator  performance: 

•  Objective  measures  of  the  adequacy  of  OMI  ease  of  use  and  usefulness  through  usability 
testing. 

System  Performance: 

•  Demonstration  of  the  predictability  of  the  system. 

Operator  performance: 

•  Periodic  objective  assessment  of  operator  skill-fade  (e.g.,  assess  competence  to  perform  task 
manually  at  recurrent  training  intervals). 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  situation  awareness  of  system 
functioning. 

•  Subjective  and  objective  (e.g.,  performance  errors)  assessment  of  the  adequacy  of  the 
operator’s  understanding  of  the  limitations  of  the  system. 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  situation  awareness  of  task-relevant 
objects  in  the  environment. 

Relationship  to  other  guidelines 

7.4  Provide  system  response  and  feedback 

7.5  Support  identification  and  management  of  ESS  faults  and  failures 

8.2.4  Maximize  operator  situation  awareness  by  increasing  system  transparency 
8.3.1  Keep  operators  “in-the-loop 

7.1.4  Support  operator  monitoring  of  ESS  functioning 

1.  Informative  feedback  shall  be  given  in  case  of  an  ESS  failure,  such  as  the  likely  cause 
and/or  location  of  the  failure. 
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2.  The  ESS  shall  be  designed  so  that  operators  are  able  to  monitor  the  ESS  and  the 
functionality  of  its  hardware  and  software,  including  the  display  of  status  and  trend 
information,  as  needed. 

3.  ESS  tasks  shall  be  designed  so  that  operators  are  involved  in  active  control  and 
monitoring  rather  than  just  passive  monitors. 

4.  System  designers  shall  allow  adequate  cognitive  resources  for  monitoring  of  the  ESS  by 
ensuring  that  task  load  does  not  become  excessive. 

5.  Operators  shall  not  be  required  to  perform  purely  monitoring  tasks  for  longer  than  20 
minutes  at  a  time. 

6.  Important  events  shall  occur  in  the  same  location  on  a  display  in  order  to  promote 
effective  monitoring  performance,  including  when  operators  must  monitor  multiple 
displays. 

7.  The  ESS  shall  provide  some  type  of  indication  the  system  is  still  being  monitored  by 
some  automatic  system. 

8.  Critical  ESS  functions  shall  be  independently  monitored  by  the  operator.  A  critical 
function  is  a  function  that  can  cause  system  failure  when  a  malfunction  is  not  attended  to 
immediately. 

9.  Operators  shall  be  given  an  adequate  understanding  (mental  model)  of  how  the  ESS 
works  in  order  to  monitor  effectively. 

10.  Intermittent  periods  of  task  monitoring  by  the  operator  shall  be  used  during  extended 
periods  of  task  automation  to  improve  monitoring  of  the  ESS. 

11.  The  effects  on  vigilance  due  to  the  use  of  ESS  shall  be  considered  before  automating 
tasks  or  functions. 

12.  The  ESS  shall  behave  predictably  so  that  the  operator  knows  the  purpose  of  the  ESS 
functioning  and  how  the  task  will  be  affected  by  that  functioning. 

13.  The  ESS  shall  provide  means  to  indicate  to  the  operator  that  data  are  missing,  incomplete, 
unreliable,  or  invalid  or  that  the  system  is  relying  on  backup  data. 


Source 

EIFDS,  Parasuraman97,  SheridanOO,  Endsley99. 
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Discussion 


Gl.  Different  messages  shall  be  given,  depending  on  whether  the  error  is  due  to  the  central 
system  or  whether  the  error  is  local. 

G2.  One  way  that  this  can  be  accomplished  is  by  providing  the  operator  with  access  to  raw 
data  that  the  ESS  processes. 

G3.  Failures  in  ESS  functioning  may  be  easier  to  detect  when  operators  are  involved  in  both 
active  control  and  monitoring,  than  when  they  are  just  passive  monitors. 

G4.  Operators  using  ESS  may  experience  higher  levels  of  mental  workload  than  manual 
controllers  due  to  monitoring,  diagnosis,  and  planning,  with  significant  cognitive  demand 
resulting  from  relatively  “simple”  vigilance  tasks. 

G5.  Operators  may  become  complacent  in  monitoring  an  ESS  if  they  have  other  tasks  to 
complete  simultaneously.  Such  decrements  in  operator  monitoring  of  an  ESS  have  been  observed 
to  occur  in  the  laboratory  in  as  little  as  20  minutes. 

G6.  Operators  will  be  able  to  detect  a  particular  event  more  easily  if  they  know  where  that 
event  will  occur  (i.e.,  spatial  certainty).  Spatial  uncertainty  has  been  shown  to  increase  perceived 
workload  and  decrease  performance  efficiency.  If  operators  do  not  know  where  on  a  display  an 
event  will  occur  then  they  must  engage  in  visual  scanning  to  look  for  the  event. 

G8.  When  a  function  is  critical,  combining  the  monitoring  of  that  critical  function  with  other, 
possibly  less  critical  functions  may  lead  to  delays  in  response.  When  a  critical  function  is 
independently  monitored,  an  operator  can  respond  to  a  malfunction  very  quickly  (within  one 
second).  If  an  operator  is  attending  to  another  task  when  there  is  a  malfunction,  there  will  be  a 
delay  in  the  operator’s  response  (several  seconds).  In  this  period  of  delayed  response,  the 
malfunction  can  cause  the  system  to  fail.  For  this  reason,  critical  functions  require  constant 
attention.  Critical  ESS  functions  do  assist  in  the  completion  of  critical  tasks;  however,  they  do  not 
assist  in  freeing  the  operator  to  attend  to  other  tasks. 

G9.  Operators  must  possess  accurate  mental  models  of  the  ESS  in  order  to  monitor 
effectively,  comprehend  current  situations,  plan  their  actions,  predict  future  system  states, 
remember  past  instructions,  and  diagnose  system  failures.  One  way  to  establish  adequate  mental 
models  is  through  training. 

G10.  Complacency  is  a  major  concern  with  the  automation  of  tasks.  If  practicable  (i.e.,  the 
operator  is  able  to  perform  the  task(s)  manually),  intermittent  periods  of  manual  control  have 
been  advocated  as  a  means  of  minimizing  complacency.  Decrement  of  cognitive  abilities  such  as 
situation  awareness  and  the  loss  of  manual  skills  may  also  occur,  making  transitions  from 
automated  to  manual  systems  difficult.  Because  automation  of  tasks  can  decrease  basic  manual 
skills,  these  skills  should  be  used  and  maintained,  if  practicable.  Intermittent  periods  of  manual 
control  during  which  ESS  functioning  is  suspended  periodically  can  promote  optimal  operator 
performance,  and  allow  better  recovery  from  failure,  regardless  of  the  type  of  task  that  is 
automated. 

Gil.  A  vigilance  decrement,  that  is,  a  continuously  decreasing  ability  to  maintain  attention 
over  time  while  monitoring,  may  occur  with  the  automation  of  tasks.  Vigilance  decrements  do  not 
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occur  because  monitoring  tasks  are  under-stimulating.  Rather,  they  require  a  large  amount  of 
cognitive  resources  and  are  often  frustrating.  Vigilance  decrements  have  been  observed  to  occur 
for  both  expert  and  novice.  How  hard  the  operator  must  work  in  order  to  maintain  vigilance  can 
be  determined  by  at  least  two  factors.  First,  workload  is  affected  by  the  ease  with  which  relevant 
signals  can  be  detected.  Signals  that  have  low  salience  are  more  difficult  to  detect  than  signals 
high  in  salience.  Visual  fatigue  will  also  require  more  effort  to  be  expended  in  order  to  detect  a 
signal.  Second,  musculo-skeletal  fatigue  associated  with  maintaining  a  fixed  posture  will  increase 
the  workload  needed  to  perform  optimal  monitoring. 

G12.  The  predictability  of  ESS  functioning  allows  the  operator  to  know  what  to  expect  when 
the  ESS  is  functioning  correctly.  This  makes  it  easier  for  the  operator  to  recognize  when  the  ESS 
is  not  functioning. 

Evaluation  methods  and  measures 

Operator  performance: 

•  Objective  assessment  of  the  adequacy  of  operator’s  accurate  and  timely  detection  of  ESS 
faults  and  failures. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  operator  situation  awareness  of  system 
functioning. 

Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  mental  and  physical  workload. 

Operator  fatigue: 

•  Subjective  assessment  of  the  adequacy  of  operator  fatigue. 

Operator  trust: 

•  Subjective  assessment  of  the  adequacy  of  operator  trust. 

Relationship  to  other  guidelines 

7.1.1  Employ  operator  centered  principles 

7.4  Provide  system  response  and  feedback 

8.2.4  Maximize  operator  situation  awareness  by  increasing  system  transparency 
24.23  Train  to  overcome  automation  biases 


7.2  Employ  operator-centered  OMI  design 

1.  The  ESS  and  associated  integrated  information  displays  shall  be  intuitive,  easy  to 
understand,  and  easy  to  use. 

2.  The  ESS  shall  be  simple  for  the  operators  to  learn. 
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3.  Support  the  operator  recognising  objects,  actions  and  options  rather  than  relying  on  the 
operator’s  memory  (recall). 

4.  The  ESS  interface  shall  represent  the  simplest  design  consistent  with  functions  and  tasks 
of  the  operator. 

5.  The  ESS  interface  shall  be  consistent  with  the  expectations  and  understandings  of  the 
operator  and  shall  reflect  an  obvious  logic  based  on  operator  task  needs  and  capabilities. 

6.  Navigation  aids  (e.g.,  landmarks)  shall  make  it  easy  for  operators  to  know  where  they  are 
in  the  data  space. 

7.  The  OM1  layout  shall  be  organized  according  to  the  human  perceptual  system  to  reduce 
the  operator’s  workload  (e.g.,  proximity,  matching  patterns,  unity,  continuity,  balance 
principles). 

8.  Where  possible,  spatial  representations  of  information  shall  be  used  instead  of  verbal  or 
textual  displays  to  reduce  the  amount  of  mental  computation  needed  to  perform  tasks 
(particularly  for  spatial  tasks). 

9.  Dynamic  information  (i.e.,  information  that  changes  over  time)  shall  be  presented  in  real 
time  and  on  demand  to  ensure  accurate  and  timely  decision-making. 

10.  The  ESS  shall  be  flexible  enough  to  allow  for  different  operator  styles  and  responses 
without  imposing  new  tasks  on  operators  or  affecting  overall  system  performance. 


Source 

HFDS,  Nielsen94,  Hutchins99,  Zachary97,  MS1472F,  AHC1,  DEFSTD25. 

Discussion 

G2.  Simplicity  for  the  operator  is  achieved  by  attaining  compatibility  between  the  design  and 
human  perceptual,  physical,  cognitive,  and  dynamic  motor  responsiveness  capabilities. 

G3.  Objects,  actions,  and  options  shall  be  visible  to  the  operator  at  all  times.  The  operator 
shall  not  have  to  remember  information  from  one  part  of  the  dialogue  to  another.  Instructions  for 
use  of  the  system  shall  be  visible  or  easily  retrievable  whenever  appropriate. 

G5.  Consistency  can  be  obtained  by  presenting  information  in  predictable  locations  and 
keeping  elements  of  screens  such  as  headers,  fields,  and  labels  consistent  in  appearance  and 
relative  location  throughout  a  system  or  application. 

G6.  Navigational  aids  can  be  a  visually  or  cognitively  salient  object  whose  location  can  be 
associated  with  the  locations  of  other  objects.  Landmarks,  for  instance,  help  people  form  a  mental 
model  for  an  information  space.  Because  people  perceive  other  obj  ects  in  relation  to  this  point  of 
reference,  a  landmark  will  organize  a  space  when  people  are  searching  for  information 
(navigation). 
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G7.  By  applying  human  perceptual  and  memory  characteristics  to  interface  design,  the 

amount  of  work  an  operator  must  exert  in  order  to  understand  the  information  being  presented  can 

be  reduced  and  allow  the  operator  to  focus  on  important  information. 

Evaluation  methods  and  measures 

Design  verification: 

•  Objective  measures  of  the  adequacy  of  OM1  ease  of  use  and  usefulness. 

•  Subjective  assessment  of  the  adequacy  of  system  usability  and  utility. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  perceptions  of  system  usability  and 
utility. 

Relationship  to  other  guidelines 

7.1.1  Employ  operator  centered  principles 

7.2  Employ  operator-centered  OM1  design 

23.1  Adopt  operator-centered  design  principles 

7.3  Support  different  modes  of  operation 

1.  Modes  shall  be  used  in  a  complex  ESS  to  partition  the  possible  operator  actions  so  that 
not  all  tasks/actions  are  available  at  the  same  time.  Modes  shall  be  used  where  the 
operator  is  likely  to  remain  in  a  system  mode  for  a  period  of  at  least  some  minutes. 

2.  When  control,  display,  or  automation  functions  change  in  different  modes  of  ESS 
operation,  mode  and  function  identification  and  status  shall  be  clear  and  distinct  to  the 
operator  by  providing  feedback  and  clear  status  indicators  (e.g.,  sound  effects  or  visual 
indication). 

3.  Seldom-used  ESS  modes  and  functions  shall  be  clearly  identified.  As  an  ESS  becomes 
more  complex  with  many  modes  and  functions,  the  cognitive  burden  caused  by  the  need 
for  mode  awareness  increases.  Seldom-used  ESS  modes  and  functions  will  pose  the 
largest  burden  on  the  operator  because  of  a  lack  of  familiarity.  Enabling  the  operator  to 
immediately  recognize  the  purpose  of  ESS  modes  and  functions  can  lessen  this  burden. 

4.  Frequently  used  ESS  modes  shall  be  more  accessible  than  infrequently  used  ESS  modes. 

5.  The  number  of  different  modes  for  a  given  ESS  shall  be  minimized. 

6.  The  operator  shall  be  able  to  easily  switch  between  ESS  modes. 

7.  The  ESS  shall  alert  the  operator  to  the  implications  of  interactions  between  modes, 
especially  when  they  are  potentially  hazardous. 
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8.  The  ESS  shall  either  prevent  the  use  of  potentially  unsafe  modes  or  alert  the  operator  that 
a  particular  mode  may  be  hazardous. 


Source 

HFDS,  Nielsen94,  MS1472F,  DEFSTD25. 

Discussion 

Gl.  Modes  can  be  a  frequent  source  of  operator  error  because  operators  often  mistake  the 
current  mode,  often  from  a  lack  of  effective  feedback  on  the  state  of  the  ESS  (including  which 
mode  is  active).  For  example,  a  flight  management  system  might  include  modes  relating  to  the 
cruise  and  descent  phases  of  the  flight.  In  this  case,  the  same  cockpit  controls  are  used  to 
manipulate  different  flight  variables  (e.g.,  speed  versus  descent  rate)  according  to  which  mode  the 
pilot  has  selected.  If  it  is  not  clear  to  the  pilot  which  mode  the  automation  is  in;  potentially 
dangerous  flight  parameters  could  be  inputted  inadvertently  into  the  system. 

G2.  Related  systems  shall  have  identical  coding  strategies,  identical  access  and  execution  of 
system  commands,  consistent  data  display  formatting,  and  consistent  monitoring  and  reporting  of 
resources. 

G5.  Multiple  modes  will  provide  a  means  of  flexibility  but  will  introduce  more  opportunities 
for  error.  Furthermore,  a  system  that  has  multiple  modes  of  operation  can  be  difficult  to  learn  and 
can  produce  increases  in  workload. 

Evaluation  methods  and  measures 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  operator  situation  awareness  of  system 
functioning  in  particular  mode  status  (i.e.,  mode  awareness). 

Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  workload. 

7.4  Provide  system  response  and  feedback 

1.  The  ESS  shall  continuously  inform  the  operator  about  what  it  is  doing,  the  purpose  for 
doing  so  and  how  it  is  interpreting  the  operator’s  input.  For  every  operator  action,  there 
shall  be  some  feedback  from  the  ESS.  For  frequent  and  minor  actions,  the  response  can 
be  modest  while  for  infrequent  and  major  actions,  the  response  shall  be  more  substantial. 

2.  Feedback  messages  shall  be  phrased  in  a  clear  and  precise  manner  and  the  use  of 
abbreviations,  and  reference  system  shall  be  avoided. 

3.  The  ESS  shall  provide  a  positive  feedback  to  the  operator  regarding  the  acceptance  or 
rejection  of  a  data  entry.  When  fixed- function  key  activation  does  not  result  in  an 
immediately  observable  response  from  the  ESS,  the  operator  shall  be  given  an  indication 
of  ESS  acknowledgment. 
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4.  The  ESS  shall  keep  the  operator  aware  on  a  continuing  basis  of  the  function  (or 
malfunction)  of  each  automated  sub-system  and  the  results  of  that  function  (or 
malfunction).  It  is  important  to  keep  the  operator  “in-the-loop”  (i.e.,  provide  sufficient 
transparency  of  the  system  for  the  operator  to  maintain  adequate  awareness  of  the 
system’s  functioning). 

5.  The  ESS  shall  alert  the  operator  when  a  problem  or  situation  is  beyond  its  capability. 

6.  The  ESS  shall  alert  the  operator  to  any  new/important  developments  occurring  in  the 
processing  and  predicting  of  outcomes  and  models. 

7.  Response  times  shall  be  as  fast  as  possible.  Normally,  no  special  feedback  is  necessary 
during  delays  of  more  than  .01  second  but  less  than  1.0  second.  For  delays  between  2  and 
10  seconds,  a  “busy”  indicator  shall  be  given  to  indicate  how  much  computer  processing 
has  been  done.  For  delays  longer  than  10  seconds,  percent-done  progress  feedback  is  to 
be  given  to  indicate  when  the  computer  expects  to  be  done  (e.g.,  percent-done  indicator). 


Source 

HFDS,  DEFSTD25,  Parasuraman99,  MS1472F,  DISA,  Endsley96. 

Discussion 

When  feedback  is  poor,  ESS  functioning  is  considered  to  be  silent.  Silent  automation  may  result 
in  coordination  and  system  failures.  Operators  may  be  surprised  by  the  behaviour  of  silent 
automation. 

Evaluation  methods  and  measures 

Design  verification: 

•  Subjective  assessment  of  the  adequacy  of  system  feedback. 


Operator  performance: 

•  Objective  assessment  of  the  adequacy  of  the  operator’s  accurate  and  timely  detection  of  ESS 
faults  and  failures. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  operator  situation  awareness  of  ESS  functioning. 

Relationship  to  other  guidelines 

7.1.4  Support  operator  monitoring  of  ESS  functioning 

8.2.4  Maximize  operator  situation  awareness  by  increasing  system  transparency 
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7.5  Support  identification  and  management  of  ESS  faults  and 
failures 

1.  Make  ESS  failures  apparent  by  making  failure  unambiguously  obvious  to  the  operator. 

2.  Provide  adequate  early  warning  notification  of  pending  ESS  failure  or  performance 
decrements  to  allow  the  operator  to  adjust  to  the  new  task  load  and  take  manual  control. 

3.  Inform  the  operator  of  potential  ESS  failure  and  malfunctions. 

4.  The  first  alarm  event  shall  be  clearly  identifiable  so  that  the  operator  is  able  to  identify 
the  first  event  in  case  of  a  series  of  alarm  events. 

5.  Provide  sufficient  diagnostic  information  that  is  self-explanatory  and  in  plain  English. 

6.  Error-prone  conditions  shall  be  minimized  by  maintaining  operator  awareness,  providing 
adequate  training,  and  developing  standard  operating  procedures. 


Source 

HFDS,  DEFSTD25,  MS1472F,  Parasuraman97. 

Discussion 

G1 .  Stress,  preoccupation,  and  distraction  may  reduce  the  operator’s  ability  to  detect  faults. 

G2.  In  situations  where  ESS  failure  would  require  operator  intervention,  it  is  useful  for  the 
operator  to  be  warned  that  he  or  she  will  need  to  take  manual  control  before  the  ESS  fails.  Ideally, 
this  warning  needs  to  come  in  adequate  time  to  allow  the  operator  to  adjust  to  the  new  task  load. 
There  may,  however,  be  cases  where  it  is  not  possible  to  provide  advance  notification  of  pending 
failure  or  where  the  estimate  of  time  needed  for  the  operator  to  take  control  is  unknown. 

G3.  It  can  increase  workload  for  the  operator  to  continually  monitor  the  ESS  for  failure. 
Advance  knowledge  about  potential  failures  can  also  help  the  operator  prepare  to  take  manual 
control. 

G4.  In  order  for  the  operator  to  diagnose  the  ESS,  diagnostics  information  needs  to  be  self- 
explanatory  and  in  plain  language.  The  diagnostic  information  must  provide  the  operator  with  the 
information  they  need  without  requiring  the  operator  to  seek  additional  references,  or  a  help 
function,  to  understand  the  problem  and  the  recommended  solution. 

G5.  Errors  may  arise  from  data  entry  errors,  monitoring  failures,  system  workarounds,  and 
mode  misapplication.  Error-prone  conditions  in  an  ESS  may  result  from  lack  of  mode  awareness, 
lack  of  situation  awareness,  lack  of  systems  awareness,  increased  heads  down  time,  over¬ 
dependence  on  automation,  and  interrupted  crew  coordination.  Automation-related  errors  usually 
occur  in  conjunction  with  other  factors  such  as  haste,  inattention,  fatigue,  or  distraction. 

Evaluation  methods  and  measures 

Design  verification: 
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•  Verification  that  system  provides  clear  and  timely  notification  of  pending  ESS  failures. 

•  Verification  that  a  suitable  training  program  and  standard  operating  procedures  exists. 

Operator  performance: 

•  Objective  assessment  of  the  adequacy  of  the  operator’s  accurate  and  timely  detection  of  ESS 
faults  and  failures. 

•  Objective  assessment  of  the  adequacy  of  the  operator’s  accurate  and  timely  management  of 
ESS  faults  and  failures. 

•  Objective  assessment  of  the  adequacy  of  the  operator’s  ability  (e.g.,  speed  and  error)  to 
resume  manual  control. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  operator  situation  awareness  of  ESS  functioning. 

•  Objective  assessment  of  the  adequacy  of  the  operator’s  ability  to  anticipate  future  ESS 
failures. 

Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  workload. 

Operator  trust: 

•  Subjective  assessment  of  the  adequacy  of  operator  trust  in  the  ESS  functioning. 

Relationship  to  other  guidelines 

7.1.3  Promote  ESS  robustness  and  resilience  to  operator  error 
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8  Class-specific  ESS  guidelines 


8.1  Information  management  aids 

8.1.1  Optimize  information  presentation  and  information  management 

1 .  Information  presented  to  the  operator  shall  accurately  reflect  system  and  environment  status 
in  a  manner  so  that  the  operator  rapidly  recognizes,  easily  understands,  and  easily  projects 
system  outcomes  in  relation  to  system  and  operator  goals. 

2.  Data  changes  that  occur  following  an  Information  Management  Aid  display  update  shall  be 
temporarily  highlighted. 

3.  Reduce  amount  of  information  the  operator  must  evaluate. 

4.  The  Information  Management  Aid  shall  provide  both  information  about  an  object’s  features 
and  explanatory  descriptions  which  support  various  decision  making  processes.  For  example, 
a  track’s  features  determining  its  intent  and  capability  (i.e.,  its  “threatiness”)  shall  be 
displayed  and/or  easily  accessible. 

5.  The  Information  Management  Aid  shall  be  able  to  effectively  evaluate,  integrate,  and  present 
information  to  the  operator  so  that  an  accurate  synthesized  picture  of  the  situation  is  achieved. 

6.  Information  presented  by  the  Information  Management  Aid  shall  be  clear,  meaningful, 
consistent,  legible,  discriminable,  and  structured  and  based  on  an  understanding  of  the  tasks 
performed  by  operators. 

7.  Information  shall  be  unambiguous  and  meaningful  to  the  operator. 

8.  When  information  must  be  updated  quickly,  the  most  important  information  shall  be  cued  to 
ensure  it  will  be  the  first  to  be  processed  by  the  operator.  It  is  important  that  the  cues  shall  be 
correct,  as  there  may  be  significant  costs  of  invalid  cueing. 

9.  Incoming  messages  shall  be  queued  automatically  by  the  Information  Management  Aid  so 
they  do  not  disrupt  current  information  handling  tasks. 

10.  Long  lists  of  information,  tasks,  and  so  on,  shall  be  stored  and  prioritized  by  the  ESS  to 
minimize  the  number  of  decision  alternatives  and  reduce  the  visual  processing  load  of  human 
operators. 

1 1 .  Information  Management  Aid  information  shall  be  automatically  reorganized  into  integrated 
or  non-integrated  arrangements  depending  on  the  current  system  status. 

12.  The  Information  Management  Aid  shall  provide  accurate  and  reliable  information. 

13.  The  Information  Management  Aid  shall  automatically  notify  the  operator  of  meaningful 
patterns  or  events  such  as  when  it  predicts  a  future  problem. 
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14.  The  Information  Management  Aid  shall  present  information  at  the  level  of  detail  that  is 
appropriate  to  the  immediate  task,  with  no  more  information  than  is  essential. 

15.  The  Information  Management  Aid  shall  avoid  repeating  information  that  is  already  available. 

16.  The  Information  Management  Aid  shall  be  fully  integrated  and  consistent  with  the  rest  of  the 
OM1. 

Source 

HFDS,  D1SA,  DEFSTD25,  Hutchins99,  AHC1. 

Discussion 

Gl.  Communication  will  be  improved  by  allowing  information  to  be  presented  in  the  most 
understandable  format.  Eliminating  the  need  to  translate  information  into  a  specific  format  will 
reduce  workload. 

G2.  A  primary  objective  of  information  automation  is  to  maintain  and  enhance  situation 
awareness.  Flowever,  too  much  information  presented  simultaneously  may  become  cluttered  and 
make  visual  search  difficult,  interfering  with  status,  decision-making,  or  control.  It  is  important 
for  the  operator  to  be  able  to  easily  locate  needed  information.  The  operator’s  ability  to  detect  a 
signal  while  monitoring  varies  inversely  with  the  rate  at  which  neutral  background  events  are 
repeated.  There  is  also  good  evidence  that  the  ability  to  accurately  define  an  event  as  a  signal  is 
improved  if  the  operator  has  a  good  understanding  of  what  a  non-signal  is. 

G7.  Where  information  coding  techniques  are  used,  the  meaning  associated  with  codes  shall 
be,  as  far  as  possible,  based  on  associations  with  which  the  target  population  can  be  expected  to 
be  familiar  (such  as  "Red  =  Danger").  Words,  names,  and  abbreviations  shall  be  based  on 
language  and  terminology  used  by  the  target  operator  population.  Data  parameters  and  units  shall 
use  formats  which  are  meaningful  to  the  target  operators  and  consistent  with  the  overall  task 
context. 

Gl  1.  Integrated  information  arrangement  allows  the  operator  to  assess  the  overall  status  of  the 
system.  Integrating  display  components  into  aggregated  arrangements  may  reduce  the  attention 
demands  of  fault  detection.  Non-integrated  arrangement  of  components  draws  operator  attention 
to  system  errors  or  other  relevant  information  (i.e.,  “pop-out”). 

G12.  Accurate  and  reliable  information  will  increase  the  operator’s  trust  in  the  system,  support 
the  decision  making  process,  and  increase  the  likelihood  of  an  appropriate  course  of  action. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  compliance  with  guidelines  concerning  the  presentation  of  information. 
System  Performance: 

•  Percentage  of  data  objects  correctly  identified  and  prioritized. 

•  Percentage  of  misses  and  false  positives. 
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•  Age  of  information. 

Operator  performance: 

•  Objective  assessment  of  the  adequacy  of  the  operator’s  accurate  and  timely  detection  and 
management  of  key  events. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  situation  awareness  of  task-relevant 
objects  in  the  environment. 

Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  workload. 

Relationship  to  other  guidelines 

7.1.1  Employ  operator  centered  principles 

17.3  Data  display 

2 1  Maps  and  situation  display 

8.1.2  Optimize  display  of  information 

1.  Event  data  shall  be  combined  with  a  map  background  when  the  geographic  location  of 
changing  events  needs  to  be  shown.  This  might  be  implemented  as  an  operator-selectable 
function  to  avoid  unnecessary  levels  of  clutter. 

2.  Integrated  displays  shall  combine  various  Information  Management  Aid  information 
elements  into  a  single  representation. 

3.  Dynamic  data  that  must  be  monitored  by  the  operator  shall  be  displayed  as  a  graphic 
format. 

4.  Automated  (i.e.,  ESS  instigated)  and  non-automated  (i.e.,  operator  instigated)  cues  shall 
be  made  equally  prominent  to  enable  operators  to  collect  confirming/disconfirming 
evidence  before  deciding  on  appropriate  action. 

5.  Provide  operators  with  displays  (e.g.,  representational  aids)  that  allow  them  to  see 
directly  the  information  they  require  rather  than  infer  it  from  using  more  cognitively 
intense  levels  of  data  processing. 

6.  Display  elements  shall  only  be  integrated  if  it  will  enhance  status  interpretation,  decision¬ 
making,  situation  awareness,  or  other  aspects  of  task  performance. 

7.  Visual  representations  of  data  shall  be  used  to  (1)  present  huge  amounts  of  data,  (2)  show 
emergent  properties  of  large  amounts  of  data,  and  (3)  separate  multiple  dimensions  within 
a  single  representation. 
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8.  Graphical  displays  of  information  shall  be  used  to  reduce  the  amount  of  mental 
processing  by  allowing  operators  to  spend  less  time  searching  for  information. 

9.  Visual  representations  of  information  shall  be  used  to  represent  data  relationships. 

10.  Provide  meaningful  patterns  of  information  by  matching  the  operator’s  expertise  in  the 
domain  (skills  and  knowledge  of  the  domain). 

Source 

HFDS,  Hutchins99,  DEFSTD25,  Zachary97. 

Discussion 

G5.  Integrated  information  arrangement  allows  the  operator  to  assess  the  overall  status  of  the 
system.  Integrating  display  components  into  aggregated  arrangements  may  reduce  the  attention 
demands  of  fault  detection.  Non-integrated  arrangement  of  components  draws  operator  attention 
to  system  errors  or  other  relevant  information  (i.e.,  “pop-out”).  Presenting  the  information  in  a 
format  relevant  to  the  state  of  the  system  can  facilitate  the  ability  of  the  operator  to  quickly  and 
easily  assess  the  system  status. 

G7.  A  large  amount  of  data  (e.g.,  parametric)  could  be  portrayed  graphically  for  rapid 
assimilation  by  the  operator.  For  instance,  the  operator  could  see,  at  a  glance,  a  synthesized 
picture  of  the  track’s  behaviour.  Compared  with  more  complex  logical  operations,  this  rather 
simple  perceptual  operation  allows  operators  to  omit  steps  that  are  otherwise  necessary  when  a 
task  is  performed  without  a  visual  representation. 

G8.  The  graphical  presentation  of  information  allows  operators  to  substitute  less  demanding 
perceptual  operations  for  more  complex  logical  operations.  That  is,  graphical  displays  allow 
decision  makers  to  “see”  directly  the  information  they  require  rather  than  infer  it.  For  example, 
determining  a  change  in  altitude  (and  the  degree  of  change)  can  be  immediately  apparent  when 
the  operator  glances  at  a  line  graph  depicting  a  track’s  history.  Meanwhile,  graphics  can  help 
operators  save  time  when  searching  for  needed  information  when  several  related  dimensions  of 
information  are  encoded  in  a  single  graphical  object.  Novel  graphical  displays  must  be  evaluated 
carefully  to  ensure  that  the  operator  interprets  the  graphical  information  in  the  way  intended  by 
the  designer. 

G9.  The  Information  Management  Aid  can  visually  represent  (1)  system  relationships,  its  rule 
network,  and  reasoning  process;  (2)  visual  associations  between  related  information;  and  (3)  new 
relationships  previously  seen  as  unrelated. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  compliance  with  relevant  guidelines  concerning  the  presentation  of 
information. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  operator  situation  awareness  of  task-relevant 
obj  ects  in  the  environment. 
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Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  workload. 

Relationship  to  other  guidelines 

17.3  Data  display 

8.2  Decision  making  aids 

8.2.1  Ensure  appropriate  implementation 

1.  Decision  making  aids  shall  be  used:  for  managing  system  complexity;  for  assisting 
operators  in  coping  with  information  overload,  for  focusing  the  operator’s  attention;  for 
assisting  the  operator  in  accomplishing  time-consuming  activities  more  quickly;  when 
limited  data  results  in  uncertainty;  for  overcoming  human  limitations  that  are  associated 
with  uncertainty,  the  emotional  components  of  decision-making,  finite-memory  capacity, 
and  systematic  and  cognitive  biases;  and,  for  assisting  the  operator  in  allocating 
resources,  managing  detailed  information,  performing  computations,  and  selecting  and 
deciding  among  alternatives. 

2.  The  decision  making  aid  shall  not  be  implemented  when  solutions  are  obvious;  when  one 
alternative  clearly  dominates  all  other  options;  when  there  is  insufficient  time  to  act  upon 
a  decision;  when  the  operator  is  not  authorized  to  make  decisions;  or  for  cognitive  tasks 
in  which  humans  excel,  including  generalization  and  adapting  to  novel  situations. 

3.  The  decision  making  aid  shall  assist,  rather  than  replace,  human  decision  makers  by 
providing  data  for  making  judgments  rather  than  commands  that  the  operator  must 
execute. 

4.  The  operator  shall  be  able  to  configure  the  decision  making  aid  to  provide  the  kind  and 
level  of  support  he/she  requires. 


Source 

HFDS,  Hutchins99,  ACH1,  Zachary97,  D1SA,  Parasuraman97. 
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Discussion 


Gl.  The  objective  of  a  decision  making  aid  is  to  increase  the  speed  of  analysis  of  tactical  data 
and  allow  for  a  more  accurate  course  of  action  and  decision  timeliness  and  agility. 

G3.  Research  has  shown  that  experienced  decision  makers  recognize  the  situation  or  scenario 
based  on  comparison  of  the  features  of  the  current  situation  with  stored  memory  representations. 
Once  the  situation  is  recognized,  solutions  or  course  of  action  are  stimulated  by  activation  of 
these  memory  representations. 

G4.  Operators  shall  be  able  to  determine  when  and  how  the  decision  making  aid  should  be 
used. 

Evaluation  methods  and  measures 

Operator  decision  making  quality: 

•  Subjective  assessment  of  the  adequacy  of  the  quality  of  the  operator’s  situation  assessment 
processes. 

•  Objective  assessment  of  the  adequacy  of  the  timeliness  and  agility  of  operator  decision 
making. 

•  Objective  assessment  of  the  adequacy  of  the  consistency  of  operator  decision  making. 

•  Subjective  assessment  of  the  adequacy  of  the  justifiability  and  rationality  of  operator 
decision  making. 

Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  workload. 

Operator  trust: 

•  Subjective  assessment  of  the  adequacy  of  operator  trust. 

Relationship  to  other  guidelines 

8.2.2  Support  decision  making  strategies 

8.2.2  Support  decision  making  strategies 

1.  The  decision  making  aid  shall  support  decision  alternatives. 

2.  When  more  than  one  alternative  is  available,  the  decision  making  aid  shall  provide 
alternatives  in  a  recommended  prioritization  scheme  based  on  mission  and  task  analysis. 

3.  When  the  information  used  by  a  decision  making  aid  is  derived  or  processed,  the  data 
from  which  it  is  derived  shall  be  either  visible  or  accessible  for  verification. 

4.  The  decision  making  aid  shall  be  capable  of  planning  a  strategy  to  address  a  problem  or 
guide  a  complex  process. 
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5.  Develop  models  of  decision  making  strategies  specific  to  the  domain  and  the  mission. 
From  the  decision  making  model,  the  type  of  information  to  display  and  how  to  display  it 
will  become  evident. 

6.  The  decision  making  aid  shall  keep  the  number  of  response  options  to  a  manageable 
number. 

7.  The  support  provided  by  the  decision  making  aid  shall  be  consistent  with  operator 
cognitive  strategies  and  expectations  (mental  models). 

8.  The  decision  making  aid  shall  be  able  to  predict  future  data  based  on  historical  data  and 
current  conditions. 

9.  The  decision  making  aid  shall  minimize  queries  by  the  operators  for  information. 

10.  The  decision  making  aid  shall  be  tailored  to  the  expertise  and  skill  of  the  decision  maker 
and  the  support  for  one  level  of  expertise  shall  not  interfere  with  the  support  for  operators 
with  different  levels  of  expertise. 


Source 

HFDS,  Hutchins99,  ACH1,  Zachary97,  D1SA,  Parasuraman97. 

Discussion 

Gl.  Arguments  leading  to  system  results  and  alternative  solutions  shall  be  displayed  so  that 
the  operator  is  able  to  comprehend  and  evaluate  computer-generated  proposals  and  formulate  a 
well-informed  decision. 

G3.  Data  that  are  not  critical  for  an  operation  can  be  made  available  only  upon  request. 

G4.  Ensure  that  the  decision  making  aid  guides  the  operator  through  the  process,  providing 
automated  guidance  on  how  to  define  and  analyze  a  problem  and  formulate  a  decision. 

G6.  The  number  of  options  that  the  operator  must  consider  is  expected  to  decrease  when  a 
decision  making  aid  is  used.  Reducing  the  response  options  focuses  the  operator’s  attention  onto 
the  most  viable  options.  Flowever,  presenting  too  few  options  might  promote  “cognitive  tunnel 
vision”,  which  should  be  avoided. 

G7.  A  mental  model  is  an  individual’s  understanding  of  the  processes  underlying  system 
operation. 

G10.  For  instance,  novices  to  the  domain  may  rely  on  a  rule-based  interface  (i.e.,  analytical)  to 
aid  in  their  decision  process  while  experts  may  be  more  responsive  to  mental  imaging  techniques 
(e.g.,  Recognition-Primed  Decision  or  feature  matching).  Novices  typically  have  good  knowledge 
of  the  domain  (i.e.,  C2  processes)  but  it  is  composed  largely  of  facts  and  basis  concepts.  Decision 
making  strategies  generally  involve  analyzing  multiple  variables  and  applying  general,  domain- 
independent  problem  solving  methods  (e.g.,  trial  and  error).  As  the  operator  becomes  more  adept, 
the  consolidated  knowledge  and  problem  solving  approaches  support  the  use  of  seemingly  more 
recognition/case-based  approaches.  Such  an  operator  has  developed  a  complex  set  of  integrated 
declarative  (the  “what”)  and  procedural  (the  “how  to”)  knowledge  both  about  the  domain  and 
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about  the  decision  tasks  to  be  performed  in  the  domain.  This  rich  mental  model  of  the  domain 
allows  the  operator  to  apply  elaborated  domain-based  solutions.  The  decision  making  aid  shall  be 
designed  to  support  the  expert  decision  maker  to  recognize  the  case  into  which  a  specific  decision 
situation  fits.  The  expert  decision  maker  can  then  retrieve  the  appropriate  solution  strategy  and 
directly  apply  it  with  little  or  no  intermediate  analysis  or  reasoning. 

Evaluation  methods  and  measures 

Operator  decision  making  quality: 

•  Subjective  assessment  of  the  adequacy  of  the  quality  of  the  operator’s  situation  assessment 
processes. 

•  Objective  assessment  of  the  adequacy  of  the  timeliness  and  agility  of  operator  decision 
making. 

•  Objective  assessment  of  the  adequacy  of  the  consistency  of  operator  decision  making. 

•  Subjective  assessment  of  the  adequacy  of  the  justifiability  and  rationality  of  operator 
decision  making. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  operator  situation  awareness  of  the  reasoning 
behind  recommendations  from  the  decision  making  aid  (i.e.,  system  transparency). 

Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  workload. 

Operator  trust: 

•  Subjective  assessment  of  the  adequacy  of  operator  trust  in  the  decision  aid. 

Relationship  to  other  guidelines 

8.2.1  Ensure  appropriate  implementation 

8.2.3  Keep  operators  in  control 

1 .  Operators  shall  be  able  to  determine  when  and  how  the  decision  making  aid  shall  be  used. 

2.  The  decision  making  aid  shall  not  be  able  to  veto  operator  actions  leaving  the  operator 
without  means  to  override  or  violate  rules  that  govern  the  decision  making  aid  unless 
there  is  not  enough  time  for  the  operator  to  make  a  decision. 

3.  The  operator  shall  be  able  to  initiate  (i.e.,  over-ride)  the  automation  of  tasks  even  when  a 
task  has  been  designated  to  be  decision  making  aid-initiated. 

4.  The  decision  making  aid  shall  assist,  rather  than  replace,  human  decision  makers  by 
providing  data  for  making  judgments  rather  than  commands  that  the  operator  must 
execute. 
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5.  The  decision  making  aid  shall  allow  the  operator  to  receive  direct  assistance  in  planning 
how  to  carry  out  the  intended  task. 

6.  The  decision  making  aid  shall  accept  direction  from  the  operators  on  which  problem 
solving  strategy  to  employ  when  alternative  strategies  are  available. 

7.  Automated  tasks  or  functions  shall  not  be  able  to  jeopardize  safety  or  make  a  difficult 
situation  worse. 

8.  When  an  operator  might  need  to  operate  in  out-of-tolerance  conditions,  then  a  deliberate 
overriding  action  shall  be  possible. 


Source 

HFDS,  DEFSTD25,  MS1472F,  Parasuraman97,  SheridanOO. 

Discussion 

Gl.  Operator  acceptance  of  a  decision  making  aid  centres  on  whether  the  operator  feels  in 
control  of  the  system. 

G8.  There  may  be  cases,  particularly  in  an  emergency  situation,  when  the  operator  needs  to 
operate  in  out-of-tolerance  conditions. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  that  the  system  provides  necessary  information  and  tools  to  support  decision 
making. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  operator  situation  awareness  of  task-relevant 
obj  ects  in  the  environment. 

Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  workload. 

Operator  trust: 

•  Subjective  assessment  of  the  adequacy  of  operator  trust  in  the  decision  aid. 

Relationship  to  other  guidelines 

7.5  Support  identification  and  management  of  ESS  faults  and  failures 
8.3.1  Keep  operators  “in-the-loop 
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8.2.4  Maximize  operator  situation  awareness  by  increasing  system 
transparency 

1.  Processed  data  shall  be  accessible. 

2.  Promote  knowledge  about  the  intent  of  the  decision  making  aid  to  the  operator. 

3.  The  decision  making  aid  shall  estimate  and  indicate  the  certainty  of  analysis  and  provide 
the  rationale  for  the  estimate. 

4.  The  decision  making  aid  shall  give  the  operator  access  to  procedural  information  used  by 
the  aid. 

5.  When  the  decision  making  aid  provides  explanations  to  the  operator,  it  shall  supply  a 
short  explanation  initially,  with  the  ability  to  make  available  more  detail  at  the  operator’s 
request,  including  access  to  process  information  or  an  explanation  for  the  rules, 
knowledge -basis,  and  solutions  used  by  the  decision  aid. 

6.  When  the  decision  making  aid  provides  explanations  to  the  operator,  the  explanation  shall 
use  terms  familiar  to  the  operator  and  maintain  consistency  with  the  immediate  task. 

7.  The  decision  making  aid  shall  alert  the  operator  to  changes  in  the  status  of  important 
system  information  such  as  when  critical  information  becomes  available  during  decision 
aid  utilization. 


Source 

HFDS,  Zachary97,  Hutchins97,  DEFSTD25,  Endsley96. 

Discussion 

Gl.  Where  displays  contain  potentially  large  amounts  of  information,  consideration  shall  be 
given  to  providing  operators  with  facilities  to  manage  the  amount  and  types  of  information 
displayed  at  any  one  time.  This  can  be  achieved  by  applying  filters  and  artificial  intelligence  (e.g., 
algorithms)  based  on  the  operator’s  role  to  help  process  the  data. 

G2.  Monitoring  of  the  decision  making  aid  by  the  operator  and  the  operator  by  the  system  can 
only  be  effective  if  each  knows  what  the  other  one  is  trying  to  accomplish  (i.e.,  intent).  This 
might  be  achieved  by  displaying  the  current  goals  of  the  decision  making  operator  (as  well  as 
progress  made  towards  those  goals). 

G3.  Research  pertaining  to  the  representation  of  system  certainty  (or  uncertainty)  to  the 
operator  is  immature.  Any  attempt  to  represent  system  certainty  (or  uncertainty)  to  the  operator 
must  be  thoroughly  evaluated. 

G4.  Procedural  information  is  information  about  the  rules  or  algorithms  used  by  the  decision 
making  aid.  Knowledge  of  procedural  information  fosters  operator  acceptance  of  the  aid  because 
the  operator  is  able  to  understand  how  the  aid  functions.  As  the  operator  becomes  more  familiar 
with  a  given  situation,  he  or  she  requires  less  procedural  information. 


64 


DRDC  Toronto  TR  2009-062 


G5.  Process  information  is  the  information  about  how  the  decision  making  aid  accomplishes  a 
task.  This  information  is  required  by  operators  to  decide  whether  to  use  the  aid  in  unfamiliar 
situations  and  for  identifying  the  nature  and  extent  of  malfunctions. 


G7.  Critical  information  in  this  standard  refers  to  information  that  may  have  a  significant 
impact  on  task  completion. 

Evaluation  methods  and  measures 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  the  quality  of  operator  situation  assessment 
processes. 

•  Subjective  assessment  of  the  adequacy  of  operator  situation  awareness  of  task-relevant 
obj  ects  in  the  environment. 

•  Subjective  assessment  of  the  adequacy  of  the  operator  situation  awareness  of  the  reasoning 
behind  recommendations  from  the  decision  making  aid  (i.e.,  system  transparency). 

Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  workload. 

Operator  trust: 

•  Subjective  assessment  of  the  adequacy  of  operator  trust. 

Relationship  to  other  guidelines 

7.1.4  Support  operator  monitoring  of  ESS  functioning 

7.4  Provide  system  response  and  feedback 

8.3  Control  and  action  aids 

8.3.1  Keep  operators  “in-the-loop” 

1 .  When  tasks  are  automated,  the  tasks  shall  be  easily  understood  by  operators  and  matched 
to  the  operator’s  mental  model  of  the  task. 

2.  A  Control  and  Action  Aid  shall  provide  the  operator  with  an  appropriate  range  of  control 
options  that  are  flexible  enough  to  accommodate  the  full  range  of  operating  conditions  for 
which  it  was  certified. 

3.  To  promote  sufficient  levels  of  operator  situation  awareness  of  a  Control  and  Action  Aid, 
the  operator  shall  be  given  immediate  feedback  to  command  and  control  orders. 

4.  Override  and  backup  control  alternatives  shall  be  available  for  automated  tasks  that  are 
critical  to  the  integrity  of  the  system  or  when  lives  depend  on  the  system. 
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5.  The  operator  shall  be  able  to  initiate  and  control  the  direction  and  pace  of  the  tasks  and/or 
functions  of  a  Control  and  Action  Aid  until  the  point  at  which  operator  goals  have  been 
met. 

6.  Information  for  backup  or  override  capability  shall  be  readily  accessible. 

7.  The  Control  and  Action  Aid  shall  be  designed  so  that  operators  are  involved  in  active 
control  and  monitoring  rather  than  just  passive  monitors. 

8.  Allow  reversal  of  operator  actions  (e.g.,  “undo”  or  “cancel”  function)  and  give  clear 
indications  how  reversal  can  be  achieved. 


Source 

HFDS,  SheridanOO,  MS1472F,  DEFSTD25,  Endsley99. 

Discussion 

G2.  Highly  flexible  Control  and  Action  Aids  can  be  useful  when  the  operator  knows  how  to 
implement  the  various  options  across  a  wide  spectrum  of  operational  situations.  Flowever,  the 
multiple  options  that  are  associated  with  highly  flexible  systems  also  require  additional  cognitive 
resources  in  order  for  the  operator  to  remember  which  mode  is  active. 

G7.  An  active  role  will  decrease  the  likelihood  of  complacency  and  lower  vigilance  and  may 
increase  situation  awareness. 

G8.  In  order  to  facilitate  the  operator’s  perception  of  being  in  control  (as  opposed  to  the 
perception  of  the  Control  and  Action  Aid  being  in  control  of  the  operator),  the  Control  and  Action 
Aid  shall  allow  the  operator  an  easy  exit  out  of  as  many  interactions  as  possible.  For  example,  by 
providing  a  cancel  button,  and  undo  and  redo  operations. 

Evaluation  methods  and  measures 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  operator  situation  awareness  of  the  reasoning 
behind  the  actions  of  the  Control  and  Action  Aid  (i.e.,  system  transparency). 
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Operator  workload: 

•  Subjective  assessment  of  the  adequacy  of  operator  workload. 

Operator  trust: 

•  Subjective  assessment  of  the  adequacy  of  operator  trust. 

Relationship  to  other  guidelines 

7.1.4  Support  operator  monitoring  of  ESS  functioning 

7.4  Provide  system  response  and  feedback 

8.2.4  Maximize  operator  situation  awareness  by  increasing  system  transparency 
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9  Input  devices 


9.1  Input  device  selection 

1 .  Two  main  input  devices  shall  be  provided,  the  keyboard  and  a  pointing  device. 

2.  The  keyboard  shall  be  an  extended  COTS  design. 

3.  The  appropriate  pointing  device  shall  be  determined  for  the  application. 

4.  If  a  mouse  or  trackball  is  provided  then  these  shall  be  chosen  to  be  suitable  for  the 
Maritime  environment. 

5.  Keyboards  and  input  devices  shall  be  in  accordance  with  good  ergonomic  design 
principles. 


Source 

TBM,  MSWUE,  UCA. 

Discussion 

Input  devices  for  a  Maritime  CCS  include,  at  minimum,  a  keyboard  and  a  pointing  device.  The 
pointing  device  used  most  often  is  a  trackball  and  associated  keys.  The  use  of  a  trackball  or 
mouse  does  not  preclude  the  use  of  hard  keys  for  specific  functions.  Voice  activated  controls  are 
not  suitable  at  this  time  for  Maritime  C2  functions. 

Touch  screen  controls  are  suitable  for  infrequent  operator  tasks  (such  as  setting  up  a  system)  but 
are  not  sufficiently  developed  at  this  time  to  be  suitable  control  devices  for  ongoing  Maritime  C2 
functions. 


9.2  Interchangeability  between  input  devices 

1 .  The  pointing  device  shall  be  the  primary  means  of  user-computer  interaction. 

2.  The  keyboard  shall  be  available  for  performing  operations,  primarily  as  a  backup  or  for 
shortcuts. 

3.  Navigation  within  and  between  the  OMI  windows,  object  selection,  and  other  keyboard 
manipulations  shall  be  consistent  with  the  Microsoft  windows  style  guide. 


Source 

TBM,  DISA,  MSWUE. 
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Discussion 


Two  main  input  devices  shall  be  provided,  a  keyboard  and  a  pointing  device.  Operators  shall  be 
able  to  use  the  keyboard  and  the  pointing  device  interchangeably.  For  most  operations,  it  is 
expected  that  the  keyboard  will  be  used  primarily  as  a  backup  so  that  users  can  continue  to 
operate  a  system  if  the  pointing  device  fails.  Accordingly,  new  hardware  designs  should  be 
developed  that  permit  the  keyboard  to  be  stowed  in  an  easily  accessible  compartment,  thus 
leaving  the  work  surface  free  when  the  keyboard  is  not  in  use. 

G2.  The  statement  that  the  keyboard  may  also  be  used  primarily  for  shortcuts  was  added  to 
the  original  statement  of  this  provision. 

9.3  The  pointer 

9.3.1  General  pointer  requirements 

1.  The  following  basic  physical  operations  shall  be  supported  with  the  pointing  device: 

■  Press 

■  Drag 

■  Release 
-  Click 

■  Double  Click 

Double-click  capabilities  shall  be  accessible  by  either  single-click  or  by  press  and-release 
operations. 

A  separate,  explicit,  action,  distinct  from  cursor  position,  shall  be  required  for  the  actual 
entry  (e.g.,  enabling,  actuation)  of  a  designated  position. 

The  home  position  for  the  cursor  shall  be  consistent  across  similar  types  of  displays. 

If  the  display  includes  a  tactical  picture,  the  home  position  for  the  cursor  shall  be  at 
Ownship. 

When  fine  positioning  accuracy  is  required,  as  in  some  forms  of  graphic  and  image 
processing  applications,  the  displayed  cursor  shall  include  an  appropriate  point 
designation  feature  (such  as  crosshairs). 

The  pointer  shall  have  a  distinctive  visual  attribute  that  does  not  obscure  other  displayed 
entities. 

8.  The  pointing  device  shall  be  associated  with  a  single  pointer  on  the  screen. 

9.  The  hotspot  of  the  pointer  shall  indicate  the  precise  location  where  operations  occur. 

10.  The  pointer  shall  move  anywhere  on  the  screen. 


2. 

3. 

4. 

5. 

6. 

7. 
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1 1 .  When  users  move  the  pointing  device,  the  pointer  shall  move  in  the  corresponding 
direction. 


12.  The  pointing  device-to-pointer  movement  ratio  shall  be  close  to  1:1  for  most  user 
interactions. 

13.  The  pointer  shall  remain  in  place  until  moved  by  users;  it  shall  not  be  moved  by  an 
application. 

14.  The  pointer  shall  deviate  less  than  .05  inch  in  any  direction;  .01  inch  for  high  stability. 

15.  When  a  system  uses  multiple  physical  displays,  the  pointer  shall  move  between  multiple 
displays  when  users  move  the  pointing  device. 

16.  When  a  system  uses  only  one  physical  display,  the  pointer  shall  not  move  beyond  the 
physical  display  boundary  or  disappear  from  sight. 

17.  The  location  of  the  hotspot  shall  not  move  as  the  pointer  changes  shape.  See  Table  1 
(below)  for  a  list  of  functions  for  which  shapes  are  defined  in  the  MSWUE  guidelines. 

Table  2:  Functions  with  Defined  Pointer  Shapes 


Pointing 

The  upper-left-pointing  arrow  is  typically  the  pointer 
used  in  window  areas  for  object  selection.  The  hotspot 
is  the  arrow  point. 

4* 

Moving 

The  four-directional  arrow  pointer  indicates  a  move 
operation  in  progress.  The  hotspot  is  the  point  where 
the  arrows  intersect. 

I 

Selecting  text 

The  I-beam  pointer  is  used  in  text  areas  to  position  the 
text  insertion  cursor  and  perform  actions  on  text  (e.g., 
selecting  text).  The  hotspot  is  on  the  vertical  bar  of  the 
I-beam  one -third  from  the  top. 

I 

Processing  an 
operation 

The  hourglass  pointer  indicates  that  an  operation  is 
being  performed  in  a  window  area.  When  this  pointer  is 
displayed,  all  actions  initiated  by  either  the  pointing 
device  or  keyboard  is  ignored  in  the  area. 

m 

Processing  in  the 
background 

The  hourglass-arrow  pointer  denotes  that  the  system  is 
processing  an  action  in  the  background.  The  user  is  still 
able  to  perform  other  functions  in  spite  of  this 
processing.  The  hotspot  is  the  arrow  point. 

k? 

Context-sensitive 
help  mode 

The  question  mark-arrow  pointer  indicates  that  the  user 
is  in  a  context-sensitive  help  mode  (e.g.,  invoked  when 
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a  user  selects  the  "What's  This"  button  on  the  upper 
right  comer  of  a  secondary  window).  The  hotspot  is  the 
arrow  point. 

Zoom-in  and  zoom- 

out 

The  zoom-in  pointer  indicates  the  ability  to  "zoom-in" 
in  order  to  see  the  object  in  more  detail.  The  zoom-out 
pointer  performs  the  reverse  action. 

\ 

t  - 

Resizing  edges  in 
specific  orientations 
(vertically, 
horizontally,  etc.) 

The  resize  pointers  indicate  the  directions  for  resizing 
an  area.  The  horizontal  and  vertical  resize  pointers 
indicate  resize  in  either  the  horizontal  or  vertical 
direction.  The  diagonal  resize  pointers  indicate 
simultaneous  resize  in  both  the  horizontal  and  vertical 
directions.  The  appropriate  resize  pointer  appears  when 
the  pointer  is  placed  on  a  frame  boarder  or  size  grip. 

Resizing  a  column 

The  column  resize  pointer  denotes  the  ability  to 
increase  or  decrease  the  width  of  a  column.  This  pointer 
appears  when  the  pointer  is  positioned  on  a  column's 
vertical  border  or  when  vertically  splitting  a  window. 

_±_ 

T" 

Resizing  a  row 

The  row  resize  pointer  indicates  the  ability  to  increase 
or  decrease  the  height  of  a  row.  This  pointer  appears 
when  the  pointer  is  positioned  on  a  row's  horizontal 
border. 

0 

Not  available  as  a 
drop  target 

The  caution  pointer  appears  when  a  user  attempts  to 
drop  an  object  in  a  non-valid  area. 

■fc 

Navigate  to  linked 
reference 

The  hand  pointer  with  the  index  finger  extended 
appears  when  the  cursor  is  placed  over  a  hyperlink 
thereby  indicating  its  function.  The  hotspot  is  the  end  of 
the  index  finger. 

a 

Panning 

The  hand  pointer  with  all  the  fingers  extended  denotes 
that  the  user  is  in  the  panning  mode.  Pressing  the 
primary  mouse  button  causes  the  fingers  to  "curl"  as  in 
a  grabbing  motion. 

18.  When  the  system  identifies  individual  users  (via  a  login  process,  for  example),  then  the 
cursor  controls  shall  be  set  by  the  user.  If  individual  users  are  not  identified  then  the 
cursor  sensitivity  shall  be  fixed  and  be  compatible  with  the  required  task  and  user  skills. 

19.  If  the  cursor  is  moved  by  pressing  a  key,  releasing  the  key  shall  cause  the  cursor  to  stop 
moving. 


Source 
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TBM,  DISA,  MS1472F,  MSWUE,  UCA. 


Discussion 

G3.  Most  entry-level  computer  users  find  it  difficult  to  double  click.  Accordingly,  double 

clicking  shall  be  considered  a  short-cut  tool  for  mid-level  to  advanced  users. 

G5.  Ownship  is  the  home  position  in  the  current  Halifax-Class  CCS. 

9.3.2  Pointer  shapes 

1.  The  pointer  shapes  defined  in  MSWUE  shall  be  used  when  providing  the  functions 
identified  in  Table  4. 1 :  Functions  with  Defined  Pointer  Shapes. 

2.  The  applications  shall  redefine  pointer  shapes  only  when  the  pointer  is  in  an  application 
window. 

3.  An  upper-left-pointing  arrow  shall  be  used  for  object  selection  in  most  windows. 

4.  An  X  pointer  shape  shall  not  be  used  by  an  application. 

5.  New  pointer  shapes  shall  not  be  created  for  functions  that  already  have  a  shape. 

6.  The  MSWUE  shall  be  the  primary  reference  for  pointer  shapes,  followed  by  shapes 
defined  in  TBM. 

7.  New  pointer  shapes  shall  follow  the  details  of  designs  and  technical  guidelines  available 
in  MSWUE  (Chapter  14). 

8.  Pointer  shapes  shall  not  be  associated  with  functions  they  were  not  designed  to  represent. 

9.  New  pointer  shapes  shall  be  easy  to  see,  with  a  hotspot  that  is  obvious  and  easy  to  locate. 

10.  New  pointer  shapes  shall  suggest  their  purpose  and  shall  not  be  confiisable  with  other 
objects. 


Source 

TBM,  DISA,  MSWUE,  UCA. 

9.3.3  Pointing  device  buttons 

1.  The  Select  (S)  function  shall  be  bound  to  the  left  button  on  a  two-  or  three-button 
pointing  device.  This  button  will  be  referred  to  as  the  S  button  throughout  the  remainder 
of  this  document. 

2.  The  Transfer  (T)  function  shall  be  bound  to  the  middle  button  on  a  three-button  pointing 
device.  This  button  will  be  referred  to  as  the  T  button  throughout  the  remainder  of  this 
document. 
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3.  The  middle  button  on  a  three-button  pointing  device  shall  be  reserved  for  advance 
features  and  shall  duplicate  features  accessible  by  the  S  button. 

4.  The  Menu  (M)  function  shall  be  bound  to  the  right  button  on  a  three-button  pointing 
device.  This  button  will  be  referred  to  as  the  M  button  throughout  the  remainder  of  this 
document. 

5.  The  Transfer  function  shall  be  bound  to  the  right  button  on  a  two-button  pointing  device. 

6.  Chording  (pressing  multiple  pointing  device  buttons  simultaneously)  shall  not  be  used. 

7.  Left-handed  users  shall  be  permitted  to  exchange  the  functions  between  the  left  and  right 
buttons. 

8.  The  S  button  shall  be  considered  the  primary  button.  The  secondary  mouse  button  (by 
default  the  right  button  on  a  two-button  pointing  device)  shall  duplicate  functions  already 
accessible  by  the  primary  button. 


Source 

TBM,  D1SA,  MSWUE. 

Discussion 

Only  advanced  users  use  the  middle  button  on  a  three-button  device.  Many  users  do  not  use  the 
secondary  button  on  a  two-button  input  device.  Many  users  have  difficulty  using  a  double-click 
function.  C2  operations  require  focused  attention  to  C2  functions.  Unnecessarily  complex  control 
actions  (such  as  the  above)  should  be  avoided  so  that  the  crewmembers  can  focus  their  attention 
on  the  operations  rather  than  on  the  OM1  itself. 

G6.  MSWUE  permits  chording  to  be  used  only  for  advanced  features. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  the  adequacy  of  input  tools  for  the  operational  environment  and  consistent 
use  of  pointers  to  support  the  accurate  and  timely  access  to  the  functions. 

Operator  performance: 

•  Objective  measures  of  the  ease  of  use  and  usefulness  of  the  input  devices  and  pointers. 
Operator  acceptance: 

•  Subjective  assessment  of  the  operator’s  perceptions  of  the  ease  of  use  and  usefulness  of  the 
input  devices  and  pointers. 


DRDC  Toronto  TR  2009-062 


73 


10  Windows 


10.1  Overview 

The  following  three  types  of  windows  are  addressed  here: 

•  System  (or  root)  windows 

•  Primary  windows 

•  Secondary  windows 

The  system  window  is  a  window  that  covers  the  entire  display  on  which  all  other  windows  are 
displayed.  Only  one  system  window  is  allowed.  On  multi-monitor  systems,  each  display  contains 
a  copy  of  the  system  window.  The  operators  will  not  have  access  to  the  system  functions  through 
the  INCOMMANDS  OMI.  System  maintainers  will  need  access  to  the  system  through  another 
channel  such  as  a  separate  terminal. 

Primary  windows  provide  the  screen  area  under  which  most  applications  run.  Secondary  windows 
are  called  from  primary  windows  to  display  information  to  or  obtain  information  from  the  user. 

Secondary  windows  can  operate  in  modeless  or  modal  modes.  The  most  common  types  of 
secondary  windows  are  dialog  boxes  (message  windows),  and  menu  windows.  Secondary 
windows  are  always  displayed  in  a  consistent  location  or  in  a  location  within  the  proximity  of  the 
information  to  which  it  relates  on  the  display. 


10.2  System  windows 

10.2.1  Status  bar 

1 .  The  window  frame  shall  contain  a  status  bar. 

2.  Display  of  classification  is  not  required  for  CCS  operations. 

3.  The  classification  level  shall  be  displayed  in  the  middle  of  the  status  bar,  if  the  project 
office  requires  the  display  of  classification. 

4.  A  digital  clock  shall  be  displayed  to  the  right  end  of  the  status  bar,  showing  the 
Date/Time  Group. 

5.  An  alert  (and  messages)  indicator  (to  notify  the  operator  that  alerts  are  present)  is 
displayed  on  the  left  end  of  the  status  bar. 

6.  The  notification  of  an  alert  shall  indicate  the  priority  of  the  alert,  if  available. 

7.  The  contents  of  an  alert  (and  message)  shall  be  displayed  in  an  area  dedicated  for  that 
purpose  near  and  below  the  alert  notification  indicator. 

8.  System  alerts  shall  be  identified  distinctly  from  operational  alerts  in  the  alert  notification 
area. 
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9.  The  status  bar  shall  not  be  obscured. 


10.  The  status  bar  shall  contain  an  area  to  display  the  operator  position(s)  selected  by  the  user 
upon  login. 

1 1 .  The  operator  position(s)  currently  in  use  that  are  displayed  on  the  status  bar  shall  not  be 
colour-coded  (to  ensure  they  will  not  be  misinterpreted  as  a  security  classification  code). 

Source 

TBM,  D1SA,  UCA. 

Discussion 

The  source  documents  to  this  style  guide  call  for  a  classification  bar  in  the  system  window.  The 
INCOMMANDS  OM1  style  for  the  classification  bar  is  different  and  the  name  of  the  bar  has  been 
changed  to  Status  Bar.  The  status  bar  is  addressed  in  this  section.  Classification  bars  require 
valuable  real  estate  and  add  to  the  visual  clutter  of  the  display,  without  adding  operational  value. 
Accordingly,  it  is  recommended  that  the  classification  information  be  optional  for  Canadian 
Maritime  systems.  Throughout  this  section  the  source  citations  have  been  retained  but  the  term 
“classification  bar”  has  been  changed  to  “status  bar”. 

G2.  Operators  report  being  aware  of  the  classification  status  of  the  information  in  the  CCS 
without  having  the  classification  status  displayed  on  the  monitor. 

G10.  If  the  project  does  not  require  the  classification  to  be  displayed,  then  the  operator 
position(s)  currently  in  use  can  be  displayed  in  the  centre  of  the  status  bar. 

Gil.  The  operational  requirement  to  display  the  operator  positions  that  are  currently  occupied 
should  be  validated  with  user  testing.  The  requirement  to  display  all  of  the  occupied  positions 
such  as  the  Sensor  Weapons  Controller  (SWC),  Assistant  Sensor  Weapons  Controller  (ASWC), 
or  Operations  Room  Officer  (ORO)  positions  may  be  particularly  useful  if,  for  training  purposes, 
more  than  one  operator  can  occupy  the  same  operational  position. 

10.2.2  Optional  Display  of  Classification 

1.  The  Title  Bar  and  Window  Border  of  classified  windows  shall  be  colour  coded  to  display 
classification  status.  A  window  showing  detailed  classification  information  shall  be 
available  upon  selection  of  the  classification  status. 

2.  When  displayed  data  are  classified  for  security  purposes,  a  prominent  indication  of 
security  classification  level  shall  be  labelled  in  each  display. 

3.  The  classification  status  shall  be  presented  in  the  status  bar.  A  secondary  classification 
bar  shall  be  located  directly  above  the  bottom  border  and  shall  span  the  entire  width  of 
the  application  area. 

4.  All  words  identifying  the  classification  status  shall  be  centred,  in  all  capital  letters,  and  at 
least  14-point  bold  font. 
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5.  If  space  is  at  a  premium,  the  secondary  classification  bar  may  be  omitted.  If  more  space  is 
required,  the  classification  bar  may  be  omitted  and  the  title  bar  and  window  border  shall 
be  used  to  portray  classification  status. 

6.  For  a  fixed  window  that  does  not  contain  a  title  bar,  the  border  shall  remain  colour  coded 
to  display  classification  status. 

7.  When  tabular  data  are  divided  into  classifications,  the  classification  titles  shall  be 
displayed  and  sub-classifications  shall  be  identified.  When  tabular  data  extend  over  more 
than  one  page  vertically,  the  columns  shall  be  titled  identically  on  each  page. 

8.  The  root  window  provides  the  highest  level  of  classification  of  any  open  or  minimized 
window. 

9.  When  classified  windows  are  open  or  minimized,  the  root  window  shall  have  its  title  bar 
and  window  border  colour  coded  and  may  have  classification  bar(s)  if  space  permits.  This 
ensures  that  even  if  a  window  is  hidden  or  minimized,  the  root  window  will  let  the 
operator  know  the  highest  security  level  of  any  open  or  minimized  windows.  The  root 
window  title  bar  shall  not  be  covered  by  any  other  windows. 

10.  The  Unclassified  bar  shall  be  displayed  in  green,  the  Confidential  shall  be  displayed  in 
blue,  the  Secret  shall  be  displayed  in  red,  and  the  Top  Secret  shall  be  displayed  in  orange. 

1 1 .  The  classification  colours  shall  be  displayed  as  the  background  of  the  classification  text 
in  the  classification  bar. 


Source 

CSFAB,  TBM,  DISA,  MS1472F. 

Discussion 

Gl.  CSFAB  also  requires  that  the  title  bar  and  window  border  of  unclassified  windows  shall 
not  be  colour  coded. 

G5.  The  option  to  omit  the  classification  bars  and  place  the  classification  status  on  the  title  bar 
has  been  removed  due  to  the  inclusion  of  the  INCOMMANDS  status  bar  in  the  styles. 

10.3  Primary  windows 

10.3.1  Primary  window  characteristics 

1.  A  primary  window  shall  contain  the  following  elements:  Title  Bar,  Window  Menu, 
Window  Menu  button,  Minimize  Control,  Maximize/Restore  Control,  and  Resize 
Borders. 

2.  The  left  side  of  the  title  bar  shall  contain  navigation  tools  with  a  window  menu  button  as 
the  minimum  navigation  tool. 

3.  The  name  of  the  application  shall  be  left  justified  next  to  the  window  menu  button  icon. 
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4.  The  right  side  shall  contain  manipulation  tools  with  minimize,  maximize,  and  close 
buttons  as  the  minimum  manipulation  tools. 

5.  A  fixed  window  is  a  special  case  of  a  primary  window.  A  fixed  window  may  contain  a 
title  bar  but  this  is  not  a  requirement  if  space  is  limited  and  the  purpose  of  the  fixed 
window  is  clear.  It  shall  not  contain  minimize,  maximize,  or  close  buttons,  or  resize 
borders. 

6.  When  multiple  modes  of  operation  exist,  a  means  shall  be  provided  to  remind  the  user  of 
the  current  mode.  Modal  operations  shall  be  avoided. 

7.  The  content  of  the  application  area  shall  be  grouped  into  functional  sub-areas  of  like 
information.  These  sub-areas  shall  take  advantage  of  standard  window  sizes  if  possible. 

8.  Each  sub-area  shall  be  separated  from  other  sub-areas  by  spacing  or  a  framing  (lines, 
shadow,  etc.)  and  shall  be  labelled  unless  it  will  be  unambiguously  understood  by  the 
operator. 

9.  Operational  controls  (e.g.,  Quick  Action  Buttons  (QABS))  shall  be  treated  as  fixed 
windows  and  shall  not  be  obscured  or  covered  within  the  display. 


Source 

CSFAB,  MS1472F,  MSWUE,  UCA. 

Discussion 

G5.  The  requirements  for  fixed  windows  have  been  edited  to  reduce  the  number  of  menus 

required.  Fixed  windows  cannot  be  closed  and  so  should  not  have  a  close  button. 

10.3.2  Application  primary  windows 

1.  The  application  primary  window  shall  be  the  first  window  displayed  when  an  application 
is  launched. 

2.  When  an  application  primary  window  is  minimized,  all  of  its  secondary  task  windows  or 
dialog  boxes  shall  also  be  minimized. 

3.  The  application  primary  window  shall  be  the  only  window  that  can  close  the  application. 

4.  An  application  primary  window  shall  contain  the  following  elements:  Window  Menu 
Control,  Title  Bar,  Title,  Minimize  Control,  Maximize  Control,  Menu  Bar,  Resize 
Borders,  and  as  an  option,  Standard  Menus. 

5.  If  the  application  primary  window  is  the  only  primary  window  in  an  application,  then  the 
following  standard  menus  shall  be  included  in  a  menu  bar:  File,  Edit,  and  Help.  If  the 
application  primary  window  is  used  in  conjunction  with  primary  task  windows,  then  an 
Application  menu  with  the  same  name  as  the  application  and  a  Help  menu  shall  be 
included  in  the  application  primary  menu  bar. 

6.  An  application  primary  window  shall  follow  the  Microsoft  window  menu  style. 
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Source 


TBM,  MSWUE. 

Discussion 

An  application  primary  window  is  a  specific  case  of  a  primary  window.  The  application  primary 
window  provides  application  control.  When  an  application  consists  of  an  application  primary 
window  only,  the  application  primary  window  provides  access  to  the  application  top-level  tasks. 
If  an  application  primary  window  is  used  in  conjunction  with  several  primary  task  windows,  the 
application  primary  window  provides  application  control  and  management  of  primary  task 
windows. 

10.3.3  Primary  task  window 

1.  The  primary  task  window  provides  primary  working  areas  for  data  display  and 
manipulation  of  top-level  tasks. 

2.  A  primary  task  window  shall  be  used  to  display  primary  data  and  controls  for  a  top-level 
task. 

3.  A  primary  task  window  shall  be  closed  or  minimized  independently  from  other  primary 
task  windows  and  the  application  primary  window. 

4.  When  a  primary  task  window  is  minimized,  all  of  its  secondary  task  windows  or  dialog 
boxes  shall  also  be  minimized.  When  a  primary  task  window  is  minimized  processing  in 
the  window  shall  continue. 

5.  When  a  primary  task  window  is  closed,  processing  in  it  shall  stop. 

6.  A  primary  task  window  may  be  closed  but  the  application  shall  not  be  shut  down  via  a 
primary  task  window. 

7.  A  primary  task  window  shall  contain  the  following  elements:  Window  Menu  Control, 
Title  Bar,  Title,  Minimize  Control,  Maximize/Restore  Control,  Menu  Bar,  and  Resize 
Borders. 

8.  A  primary  task  window  shall  have  a  standard  Microsoft  window  menu. 
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Source 


CSFAB,  TBM,  MSWUE. 

Discussion 

G7.  This  guideline  has  been  edited  to  remove  the  requirement  to  include  standard  menus  (e.g., 

File,  Edit,  and  Help).  Standard  menus  should  be  implemented  if  supported. 

10.3.4  Fixed  windows 

10.3.4.1  Fixed  windows  characteristics 

1.  Fixed  windows  shall  be  fully  visible  to  the  operator  at  all  times.  Fixed  windows  are 
windows  that  are  vital  to  the  operation  of  the  system  and  must  be  rapidly  time-shared  by 
the  operator. 

2.  Fixed  windows  shall  be  automatically  loaded  upon  system  initialization  and  cannot  be 
closed  or  minimized. 

3.  Fixed  windows  cannot  be  re -sized  or  re-located  by  the  operator. 

4.  All  fixed  windows  shall  be  tiled  but  do  not  have  to  occupy  the  entire  display  area. 

5.  No  window  shall  overlay  a  fixed  window. 

6.  The  title  bar  and  sizing  frame  are  removed  from  fixed  windows  since  they  cannot  be 
closed,  moved  or  sized. 


Source 

CSFAB,  UCA. 

Discussion 

Fixed  windows  are  special  cases  of  primary  windows  and  are  necessary  in  Maritime  combat 
systems.  Fixed  windows  are  used  for  vital  information  that  must  be  available  to  the  operators  at 
all  times.  These  windows  cannot  be  closed  and  must  not  be  obscured  by  other  windows.  An 
example  of  a  fixed  window  is  a  CCS  tactical  display.  Because  these  windows  are  special  cases, 
they  do  not  have  the  usual  capabilities  of  application  windows.  For  example,  they  shall  not  have 
controls  that  permit  them  to  be  sized,  relocated,  or  closed. 

10.3.4.2  Specific  cases  of  fixed  windows 

1.  The  following  shall  be  fixed  windows: 

■  Message  area  (Alert  Display) 

■  Main  tactical  display  (e.g.,  contact  location,  tracks,  and  route  planning) 

■  Tactical  display  function  access  and  viewing 
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■  Primary  track  amplification 

■  Primary  function  access  (e.g.,  map  controls) 

10.4  Secondary  windows 

1.  The  display,  controls,  and  function  of  each  type  of  secondary  window  implemented  in  the 
application  shall  be  consistent  with  the  Microsoft  Windows  styles  (see  MSWUE  Chapter 
9).  Types  of  secondary  windows  include  the  following: 

■  Dialog  Windows 


Figure  2:  Example  of  a  dialogue  window 

■  Prompt  Windows 

■  Message  Windows 

■  Error  Message  Windows 


Figure  3:  Example  of  an  error  message  window 
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Information  Message  Windows 
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Figure  4:  Example  of  an  information  message  window. 
•  Question  Message  Windows 


Printers 


*j 


Are  you  sure  you  want  to  delete  the  printer  'Generic  /  Text  Only'? 


Figure  5:  Example  of  a  question  message  window. 
■  Warning  Message  Windows 


Figure  6:  Example  of  a  warning  message  window. 

■  Working  Message  Windows 

■  Selection  Window 

2.  Secondary  windows  shall  be  used  for  short-term  interaction  with  data  and  controls  that 
support  the  primary  task  of  a  primary  task  window  or  an  application  primary  window. 

3.  A  secondary  window  shall  contain  a  title  bar.  A  secondary  window  shall  contain  resize 
borders  and  a  maximize  button  if  users  are  able  to  resize  the  window. 


4.  Secondary  windows  shall  contain  either  a  menu  bar  or  an  action  area.  An  action  area  is 
more  common  and  is  provided  when  the  number  of  possible  user  actions  is  five  or  less.  A 
menu  bar  is  provided  only  if  the  number  of  possible  user  actions  is  greater  than  five  or  if 
the  user  requires  access  to  the  File  or  Edit  menus. 

5.  Message  windows  contain  a  message  area  and  an  action  area.  Users  shall  be  able  to  move 
message  windows  but  not  close,  minimize,  or  resize  them.  A  message  window  may  be 
modal  or  modeless  depending  on  its  purpose.  The  default  action  of  all  message  windows 
shall  be  non-destructive. 
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6.  The  secondary  window  title  bar  shall  contain  navigation  tools  with  a  window  menu 
button  as  the  minimum  navigation  tool.  The  navigation  tools  shall  be  located  on  the  left 
end  of  the  title  bar. 

7.  The  name  of  the  application  shall  be  left  justified  to  the  end  of  the  window  menu  button, 
followed  by  a  colon  and  then  the  file  name. 

8.  The  right  end  of  the  window  title  bar  shall  contain  manipulation  tools  with  a  close  button 
as  the  minimum  manipulation  tool. 

9.  When  a  secondary  window  is  opened,  it  shall  appear  in  front  of  the  parent  window.  The 
parent  window  shall  stay  displayed. 

10.  When  a  secondary  window  is  closed,  its  children  shall  be  closed  but  its  parent  shall  not  be 
affected. 

1 1 .  A  secondary  window  shall  not  shut  down  an  application. 

12.  A  secondary  window  shall  not  be  opened  at  application  start-up. 

13.  A  secondary  window  shall  contain  the  following:  Window  Menu  Control,  Title  Bar,  and 
Title. 

14.  The  window  menu  for  a  secondary  window  shall  only  contain  the  following:  Close  and 
Move. 

Source 

CSFAB,  TBM,  MSWUE. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  that  the  windows  conform  to  the  guidelines  in  this  section. 

Relationship  to  other  guidelines 

1 1  Window  design  guidance 

12  Windows  navigation  and  selection 

15  Windows  states,  components,  and  operations 
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11  Window  design  guidance 


11.1  Consistency  in  design  across  windows 

1.  A  consistent  organizational  scheme  for  key  elements  shall  be  used  in  all  application 
windows. 

2.  The  same  window  design  shall  be  employed  whenever  users  perform  the  same  basic  task. 

3.  Different  or  distinctive  elements  may  appear  in  a  window  to  fit  the  task  being  performed, 
but  these  elements  shall  be  consistent  across  windows  within  an  application. 

4.  Groups  of  windows  with  similar  functions  (e.g.,  a  group  of  alert  windows)  shall  be 
ordered  by  frequency  of  usage,  with  the  most  frequent  at  the  top. 


Source 

TBM,  MS1472F,  UCA. 

11.2  Arranging  information  to  match  user  actions 

1.  A  window  shall  be  designed  so  users  can  manipulate  objects  in  ways  that  support  task 
performance. 

2.  Objects  shall  be  arranged  so  users  can  move  quickly  and  easily  among  them. 

3.  Pointer  movement  and  keystrokes  needed  to  perform  a  task  shall  be  minimal. 

4.  Window  layout  shall  support  natural  scanning  order  (from  left  to  right  and  top  to  bottom). 

5.  Window  layout  shall  be  logical  to  users  and  appropriate  to  actions  executed. 

Source 

TBM,  DISA,  MS1472F. 

11.3  Arranging  information  by  importance 

1.  The  most  important  information  and  controls  shall  be  in  the  upper  left  part  of  the 
window. 

2.  The  objects  in  a  window  shall  be  arranged  to  accommodate  the  possibility  that  users  may 
resize  the  window,  if  the  window  is  resizable. 

3.  Task-critical  information  is  visually  set  apart  from  other  information  in  a  window.  At 
least  one  character  line  shall  be  left  blank  above  and  below  critical  information;  at  least 
two  character  spaces  shall  be  left  blank  to  the  left  and  right  of  critical  information. 
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Source 


TBM,  DISA,  MS1472F. 

1 1 .4  Designing  windows  to  minimize  memory  load 

1.  Users  shall  be  able  to  perform  the  task  called  for  in  a  window  without  referring  to 
external  information. 


Source 

TBM,  MS1472F. 

11.5  Window  modality 

1.  Modal  dialogs  shall  be  used  when  the  system  must  inform  the  user  of  a  situation  before 
proceeding  (e.g.,  potential  loss  of  data). 

2.  Modal  dialogs  shall  be  used  when  a  task  cannot  proceed  without  additional  information. 

3.  Dialog  windows  that  are  system  modal  shall  appear  as  the  top-most  window. 

4.  Dialog  windows  that  are  full  application  modal  shall  appear  as  the  top-most  window 
when  any  window  in  the  application  that  spawned  that  dialog  window  is  selected. 

5.  Dialog  windows  that  are  primary  application  modal  shall  appear  as  the  top-most  window 
when  the  window  that  spawned  the  dialog  window  is  selected. 

6.  Message  dialogs  shall  be  primary  or  full  application  modal. 

7.  If  a  modal  window  is  used  it  shall  contain  all  of  the  information  necessary  for  the 
operator  to  make  the  decision. 

8.  When  a  dialog  box  is  displayed  it  shall  reflect  the  current  state  of  the  system.  If  a  dialog 
box  is  modeless,  then  any  changes  to  the  application  shall  be  updated  in  the  dialog  box. 


Source 

TBM,  UCA. 
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Discussion 


A  window  is  either  modal  or  modeless.  There  are  three  levels  of  modality  as  follows: 

•  Primary  Application  Modal.  Primary  application  modal  dialogs  allow  the  user  to  interact 
with  any  other  window  on  the  display  except  for  the  window  that  is  acting  as  the  parent  for 
the  modal  dialog  window. 

•  Full  Application  Modal.  Full  application  modal  dialogs  allow  the  user  to  interact  with  any 
window  on  the  desktop  except  those  that  are  a  part  of  the  same  application  as  the  modal 
window. 

•  System  Modal.  In  the  system  modal  dialogs  the  user  is  prevented  from  interacting  with  any 
other  window  on  the  display. 

Modal  dialogs  shall  only  be  used  to  help  the  user  structure  and  keep  track  of  a  task  and  to  prevent 
user  errors. 

11.6  Widget  selection 

1 .  Option  buttons  shall  be  used  when  selecting  an  option  from  up  to  six  mutually  exclusive 
options. 

2.  An  option  menu  or  combination  box  shall  be  used  when  more  than  six  mutually  exclusive 
options  (no  more  than  10-12)  are  available. 

3.  Option  menus  are  used  to  display  small  lists  of  mutually  exclusive  options.  Option  menus 
may  be  used  in  the  place  of  a  list  or  option  buttons  when  only  one  list  selection  can  be 
made  and  when  space  is  limited.  See  MSWUE  for  the  appearance  and  behaviour  of 
option  menus. 

4.  A  list  box  shall  be  used  when  selecting  from  a  large  group  of  options  (more  than  12). 

5.  If  the  operator  must  select  a  numeric  value  then  the  following  shall  be  used: 

■  Scale  or  counter  for  continuous  values  within  a  range. 

■  Standard  Combination  Box  for  a  standard  set  of  values  normally  selected  and 
space  is  available. 

■  Drop-Down  Combination  Box  for  a  standard  set  of  values  normally  selected  and 
there  is  a  need  to  conserve  space. 

6.  If  the  operator  must  select  a  single  option  from  a  group  of  options  the  following  shall  be 
used: 

■  Option  button  if  there  are  six  or  fewer  options  and  space  is  available. 

■  Standard  Combination  Box  if  there  are  more  than  six  options  and  space  is 
available. 

■  Drop-Down  Combination  Box  to  conserve  space  or  to  avoid  clutter. 
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7.  If  the  operator  may  select  multiple  options  from  a  group  of  options  the  following  shall  be 
used: 

■  Check  box  if  seven  or  fewer  options  are  available. 

■  List  if  more  than  seven  items  are  available. 

8.  If  the  operator  must  transfer  or  copy  items  from  one  group  to  another  a  Transfer  List  shall 
be  provided. 

9.  Option  buttons  or  an  option  menu  shall  be  used  when  the  set  of  options  is  not  likely  to 
change. 

10.  A  list  box  shall  be  used  when  the  options  might  change. 

1 1 .  Push  buttons  shall  be  used  for  frequently  used  actions,  and  when  the  pointing  device  is 
already  moving. 

12.  Pop-up  menus  shall  be  used  only  when  it  is  critical  to  the  application  that  users  be  able  to 
access  functions  without  moving  the  pointing  device. 

13.  Pop-up  menus  shall  not  be  used  as  the  only  method  available  for  accessing  operations. 

14.  Option  menus  shall  be  used  when  setting  values  or  choosing  from  a  set  of  related  items. 

15.  Vertical  scroll  bars  shall  be  provided  if  the  list  is  longer  than  the  viewable  list  box  area. 
Horizontal  scroll  bars  shall  be  avoided  if  possible.  A  horizontal  scroll  bar  shall  only  be 
used  if  most  items  in  a  list  are  considerably  shorter  than  a  few  longer  items  and  screen 
space  is  limited. 


Source 

CSFAB,  TBM. 

Discussion 

G7.  CSFAB  places  the  limit  at  six. 

11.7  Coding  critical  information 

1 .  Capitalization  shall  not  be  the  sole  indication  of  critical  information  in  a  window. 

2.  When  special  symbols  are  used  to  signal  critical  conditions,  they  shall  only  be  used  for 
that  purpose. 

3.  Bolding/brightening,  colour  coding,  etc.,  shall  be  used  to  focus  attention  on  critical 
information. 

4.  Coding  shall  be  employed  to  differentiate  between  items  of  information  and  to  call  the 
user's  attention  to  changes  in  the  state  of  the  system.  Coding  shall  be  used  for  critical 
information,  unusual  values,  changed  items,  items  to  be  changed,  high  priority  messages, 
special  areas  of  the  display,  errors  in  entry,  criticality  of  command  entry,  and  contacts. 
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Consistent,  meaningful  codes  shall  be  used.  Coding  shall  not  reduce  legibility  or  increase 
transmission  time. 

5.  Colour  shall  be  used  for  alerts,  and  users  shall  be  required  to  respond  before  an  alert  is 
terminated. 

6.  When  a  user's  attention  must  be  directed  to  a  portion  of  a  graphic  display  showing  critical 
or  abnormal  data,  that  feature  shall  be  highlighted  with  some  distinctive  means  of  data 
coding. 

7.  When  a  special  symbol  is  used  to  mark  a  word,  the  symbol  shall  be  separated  from  the 
beginning  of  the  word  by  one  space. 

8.  A  maximum  of  two  levels  of  intensity  (brightness)  shall  be  used.  Brightness  shall  only  be 
used  as  a  code  if  the  objects  coded  are  adjacent.  Each  level  shall  be  separated  from  the 
nearest  other  level  by  not  less  than  a  2: 1  ratio. 

9.  Users  shall  be  alerted  to  critical  information  in  an  inactive  or  minimized  window. 

Source 

CSFAB,  TBM,  D1SA,  MS1472F. 

Discussion 

G5.  The  requirement  to  use  an  audible  alarm  was  removed  from  the  above  provision.  See 

Section  18.1  for  more  information  regarding  audible  alarms  and  alerts. 

G8.  Absolute  brightness  is  difficult  to  interpret.  Using  brightness  as  a  code  should  be  avoided. 

Brightness  refers  to  the  intensity  of  a  particular  hue. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  that  the  design  of  windows  and  window  elements  supports  the  utility  of  the 
OMI. 

Operator  performance: 

•  Objective  measures  of  the  ease  of  use  and  usefulness  of  the  windows  and  window  elements. 

•  Assessment  of  the  extent  to  which  the  design  of  the  windows  and  window  elements  support 
the  timely  access  to  critical  information  and  completion  of  critical  tasks. 
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Operator  acceptance: 

•  Subjective  assessment  of  the  operator’s  perceptions  of  the  ease  of  use  and  usefulness  of  the 
windows  and  window  elements. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  perceptibility  of  critical  information. 

Relationship  to  other  guidelines 

10  Windows 

12  Windows  navigation  and  selection 
15  Windows  states,  components,  and  operations 
18.1:  Audible  alerts  and  flash  coding 
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12  Windows  navigation  and  selection 


12.1  Window  navigation 

12.1.1  Window  mode 

1.  In  modeless  windows,  users  shall  be  able  to  interact  with  other  windows  while  the 
modeless  window  is  displayed  on  the  screen. 

2.  Modal  windows  are  used  when  the  operator  must  address  the  contents  of  the  window 
before  further  processing  can  continue  or  to  ensure  the  user  has  received  an  important 
message.  Modal  windows  shall  only  be  used  when  it  is  critical  that  the  system  obtain 
further  information  or  that  the  user  acknowledges  certain  information  before  anything 
else  can  begin. 

3.  Modal  windows  shall  not  restrict  interaction  with  windows  higher  in  the  hierarchy  unless 
it  is  critical  that  the  system  obtain  further  information  or  that  the  user  acknowledges 
certain  information  before  anything  else  can  begin. 


Source 

CSFAB. 

12.1.2  Input  focus  policy 

1 .  Only  one  window  on  the  screen  shall  have  input  focus  at  any  time. 

2.  Users  shall  assign  focus  explicitly  particularly  if  overlapping  windows  are  implemented, 
and  shall  do  so  either  with  the  pointing  device  or  from  the  keyboard. 


Source 

TBM,  DISA. 

12.1 .3  Assigning  focus  to  a  window  with  a  pointing  device  and  the 
keyboard 

1.  Users  assign  focus  by  moving  the  pointer  into  a  window  and  clicking  the  Select  (S) 
button. 

2.  If  users  click  in  an  empty  window  area,  the  window  frame  shall  highlight  and  the  window 
shall  be  raised  to  the  front. 

3.  If  users  click  in  the  title  bar,  the  frame  shall  highlight  and  the  window  shall  be  raised  to 
the  front  and  shall  receive  input  focus. 

4.  If  users  click  on  an  object  within  a  window,  the  window  frame  shall  highlight,  the 
window  shall  be  raised  to  the  front,  and  an  object  shall  be  selected. 
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5.  A  window  is  raised  by  clicking  anywhere  in  the  window.  The  window  is  then  moved  to 
the  top  of  the  window  hierarchy  (except  for  any  toolbars  or  pallets  associated  with  the 
window  being  raised)  and  is  given  input  focus.  A  window  may  also  be  raised  by  selecting 
it  from  the  open  window  menu. 

6.  <Alt>  +  <Tab>  and  <Alt>  +  <Shift>  +  <Tab>  shall  move  the  focus  forward  and 
backward  through  window  families  (i.e.,  primary  windows  and  window  icons). 

7.  <Alt>  +  <F6>  and  <Alt>  +  <Shift>  +  <F6>  move  the  focus  forward  and  backward 
through  windows  in  a  family. 

Source 

CSFAB,  TBM. 

12.2  Navigation  within  windows 

12.2.1  Pointing  device  navigation  for  controls 

1 .  Placing  the  pointer  on  a  control  and  clicking  the  S  button  shall  move  the  location  cursor 
to  the  object  and  shall  give  the  object  focus. 

2.  Pressing  the  <Ctrl>  key  and  clicking  the  S  button  on  an  object  shall  select  the  object  and 
keep  the  current  object  selected. 

3.  Autoscrolling  shall  be  available  when  the  pointer  is  on  a  scrollable  control  such  as  a  text 
block  or  a  list. 

4.  The  means  shall  be  provided  to  readily  move  the  cursor  to  the  head  or  the  foot  (end)  of  a 
file. 

Source 

TBM,  MS1472F. 

12.2.2  Keyboard  navigation  for  controls 

1 .  Cursor  tab  controls  or  other  provisions  for  establishing  and  moving  readily  from  field  to 
field  shall  be  provided  for  the  purpose  of  editing  programs  or  tabular  data. 

2.  The  <Ctrl>  +  <Tab>  and  <Ctrl>  +  <Shift>  +  <Tab>  keys  shall  move  the  location  cursor 
to  the  next  and  previous  tab  group,  respectively. 

3.  The  <Tab>  and  <Shift>  +  <Tab>  shall  move  to  the  next  and  previous  tab  group  except  in 
the  multi-line  text  widget. 

4.  The  location  cursor  shall  be  on  the  default  or  first  control  (i.e.,  top  left  most)  when  it 
moves  to  a  tab  group. 
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5.  The  location  cursor  shall  skip  a  tab  group  if  none  of  the  controls  can  have  keyboard 
focus. 

6.  The  Up,  Down,  Left,  and  Right  arrow  keys  shall  move  the  location  cursor  between 
controls  in  the  tab  group  with  focus. 

7.  Moving  the  location  cursor  to  a  control  shall  not  change  the  state  of  the  control. 

8.  The  direction  of  cursor  movement  within  a  window  shall  be  from  upper  left  to  lower  right 
and  shall  wrap  between  the  first  and  last  tab  groups  in  the  window. 

9.  Arrow  keys  shall  move  the  location  cursor  one  increment  at  a  time  (e.g.,  to  the  next  line 
in  text,  to  the  next  item  in  a  list);  <Ctrl>+ Arrow  keys  move  the  location  cursor  one  large 
increment  (e.g.,  move  the  text  cursor  to  the  next  word  instead  of  the  next  character). 

10.  The  virtual  <Home>  and  <End>  keys  shall  move  the  cursor  to  the  leftmost/rightmost 
element  in  a  control. 

11.  <Ctrl>  +  <Home>  and  <Ctrl>  +  <End>  shall  move  the  cursor  to  the  beginning/end 
element  in  a  control. 

12.  The  virtual  keys  <PageUp>,  <PageDown>,  <PageLeft>  (or  <Ctrl>  +  <PageUp>),  and 
<PageRight>  (or  <Ctrl>  +  <PageDown>)  shall  scroll  the  elements  in  the  control  up, 
down,  left,  or  right  one  page  minus  one  unit  of  information  (e.g.,  one  line  of  text)  at  a 
time. 

13.  The  title  “Window”  shall  be  in  all  application  pull-down  menu  bars  to  allow  for  the 
selection  of  hidden  windows.  The  <Alt>  +  <Tab>  keyboard  accelerator  shall  shuffle 
through  all  open  windows  in  an  application. 

14.  Keyboard  focus  shall  remain  on  the  element  where  it  was  before  scrolling  began  even 
when  the  location  cursor  may  not  be  in  view. 

15.  When  keyboard  action  alters  the  element  with  focus,  scrolling  shall  occur  so  the  element 
is  in  view. 


Source 

CSFAB,  TBM,  MS1472F. 

12.2.3  Keyboard  navigation  for  graphic  objects 

1.  Navigation  among  graphics  objects  shall  use  the  same  key  bindings  as  navigation  among 
controls. 
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Source 


TBM. 

12.3  Object  selection 

12.3.1  Pointing  device  selection  methods 

1.  Click  the  S  button  on  an  object  to  select  it.  When  another  object  is  selected,  previously 
selected  objects  are  deselected. 

2.  To  select  multiple  objects,  click  the  S  button  on  objects  one  at  a  time  while  holding  down 
the  <Ctrl>  key.  The  objects  are  highlighted  and  selected. 

3.  Where  text  has  been  specified  to  become  the  subject  of  control  entries  (e.g.,  for 
underlining,  bolding,  moving,  copying,  or  deleting),  the  affected  segment  of  text  shall  be 
highlighted  to  indicate  its  boundaries. 

4.  To  select  a  range  of  contiguous  objects,  the  pointer  shall  be  positioned  on  the  first  object 
in  the  range  to  be  selected,  and  then  the  S  button  shall  be  selected  to  set  the  anchor  for  the 
range.  Any  other  object  that  was  selected  shall  be  deselected.  The  pointer  shall  be 
dragged  until  it  is  on  the  last  object  in  the  range,  and  the  S  button  shall  be  released  to 
complete  the  selection. 

5.  To  extend  a  range  selection  the  user  shall  position  the  pointer  on  the  object  that  shall  be 
the  last  one  in  the  selection,  and  hold  down  the  <Shift>  key  while  clicking  the  S  button 
on  the  pointing  device.  The  objects  in  the  revised  selection  range  (defined  from  the 
original  anchor  to  the  current  pointer  position  in  one-dimensional  collections,  and  defined 
by  the  diagonal  from  the  anchor  to  the  current  pointer  position  in  two  dimensional 
collections)  shall  be  reselected,  and  any  elements  removed  from  the  selection  shall  return 
to  normal  appearance. 

6.  To  add  or  remove  a  non-contiguous  object  to  or  from  a  range  selection,  the  pointer  shall 
be  positioned  on  the  object,  and  then  the  <Ctrl>  key  shall  be  held  down  while  clicking  the 
S  button  on  the  pointing  device.  If  previously  unselected,  the  object  shall  be  selected  and 
highlighted.  If  previously  selected,  the  object  is  deselected  and  shall  return  to  a  normal 
appearance.  The  other  elements  in  the  selection  shall  remain  highlighted. 

7.  A  bounding  box  shall  appear  when  dragging  the  pointer  over  elements  in  a  two 
dimensional  collection. 


Source 

TBM,  MS1472F,  MSWUE. 

12.3.2  Keyboard  selection  methods 

1.  Add  mode  shall  be  used  to  select  one  element  or  multiple  objects  one  at  a  time.  Normal 
mode  shall  be  used  to  select  multiple  contiguous  objects. 
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2.  The  location  cursor  shall  be  a  solid  rectangle  in  normal  mode  and  shall  be  a  dotted 
rectangle  in  add  mode. 

3.  Add  mode  and  normal  mode  are  used  to  select  multiple  non-contiguous  objects. 

4.  <Space>  (and  the  virtual  key  <Select>)  shall  select  an  object  or  multiple  objects  one  at  a 
time. 

5.  <Space>  (and  the  virtual  key  <Select>)  shall  set  the  anchor  for  selecting  a  range  of 
contiguous  objects. 

6.  <Shift>  +  <Space>  (and  <Shift>  +  <Select>)  shall  extend  selection  from  anchor  to  last 
object  selected. 

7.  <Shift>  +  <F8>  shall  toggle  between  add  mode  and  normal  mode. 

8.  <Ctrl>  +  </>  shall  select  all  of  the  objects  in  a  collection. 

9.  <Ctrl>  +  <\>  shall  deselect  all  of  the  objects  in  a  collection. 

10.  Cancel  shall  undo  a  selection  action  and  return  the  objects  to  their  normal  appearance. 

Source 

TBM. 

Discussion 

The  keyboard  and  the  pointing  device  shall  be  used  to  make  selections.  The  normal  mode  and  the 
add  mode  are  used  to  make  keyboard  selections.  The  normal  mode  is  used  for  making  simple 
contiguous  selections  from  the  keyboard.  The  add  mode  is  used  for  making  more  complex 
selections  which  may  be  disjoint.  In  normal  mode,  the  location  cursor  and  the  highlight  are  on  the 
same  element  and  move  together  when  the  arrow  keys  are  used.  In  add  mode,  the  location  cursor 
moves  independently  of  the  highlight. 

12.3.3  Other  types  of  selection 

1 .  A  default  action  in  a  window  is  executed  by  double  clicking  when  making  a  selection. 

2.  Pressing  <Enter>  or  <Ctrl>  +  <Retum>  shall  invoke  the  default  action  after  making  a 
selection  in  a  window. 

3.  The  <Retum>  key  shall  invoke  the  default  action  in  a  window  if  the  focus  is  on  an  object 
other  than  multi-line  text. 

4.  Extended  selection  shall  be  available  in  text. 

5.  In  a  text  widget  a  single  click  shall  place  the  text  cursor,  a  double  click  shall  select  a 
word,  and  a  triple  click  shall  select  a  line  of  text. 
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6.  The  virtual  <Cancel>  key  shall  cancel  the  action  being  executed  and  shall  return  the 
object  to  its  state  prior  to  action. 


Source 

TBM. 

12.4  Object  transfer 

12.4.1  Object  transfer  overview 

1.  Individual  objects  or  a  collection  of  objects  shall  be  able  to  be  transferred  in  a  window  or 
to  another  window  in  the  same  application  as  well  as  into  other  applications.  This  shall  be 
accomplished  by  two  or  more  of  the  following  four  techniques: 

♦  Clipboard  transfer 

♦  Primary  transfer 

♦  Quick  transfer 

♦  Drag  transfer  (drag  and  drop) 

2.  The  transfer  techniques  to  be  implemented  include  at  minimum  clipboard  transfer  and 
drag  transfer  techniques. 

3.  For  each  transfer  technique  the  following  operations  shall  be  generally  available:  Copy, 
Move,  and  Link. 


Source 

TBM,  UCA. 

12.4.2  Clipboard  Transfers 

1.  When  inserting  characters,  words  or  phrases  (e.g.,  editing),  items  to  be  inserted  shall  be 
collected  in  a  buffer  area  and  displayed  in  the  prescribed  insert  area  of  the  screen  for 
subsequent  insertion  by  user  command. 

2.  Clipboard  transfer  shall  allow  users  to  move  and  copy  objects  by  transferring  them  first 
from  their  current  location  to  a  temporary  clipboard  and  then  from  the  clipboard  to  a  new 
location.  Clipboard  transfer  can  be  used,  for  example,  to  transfer  text  (e.g.,  strings  of 
characters,  blocks  of  text)  and  graphics  (e.g.,  lines,  shapes,  entire  figures)  within  or 
between  windows  or  applications. 

3.  A  clipboard  move  operation  shall  consist  of  cut  and  paste  operations;  a  clipboard  copy 
operation  shall  consist  of  copy  and  paste  operations. 

4.  Clipboard  transfer  operations  shall  be  available  whenever  an  obj  ect  that  can  be  edited  has 
keyboard  focus.  Applications  shall  provide  access  to  these  operations  as  menu  options, 
push  buttons  in  a  window,  or  other  buttons,  and  users  shall  be  able  to  execute  the 
operations  either  with  the  pointer  or  from  the  keyboard. 
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5.  Access  to  clipboard  transfers  shall  be  implemented  in  a  consistent  fashion  throughout  the 
application.  Access  to  clipboard  transfer  shall  be  available  only  when  it  is  appropriate  to 
the  task  being  performed  by  users.  Users  shall  be  able  to  view  the  contents  of  the 
clipboard  and  shall  be  informed  (e.g.,  in  a  message  window)  when  they  attempt  to  cut  or 
copy  an  object  whose  size  exceeds  the  capacity  of  the  clipboard.  The  clipboard  is  only 
displayed  at  the  request  of  the  user. 

6.  The  clipboard  transfers  operations  of  Cut,  Copy,  and  Paste  shall  be  performed  using  the 
Edit  menu  of  an  application. 

7.  Clipboard  transfer  shall  be  available  whenever  an  editable  object  has  keyboard  focus. 

8.  A  clipboard  transfer  operation  shall  be  invoked  from  pull  down  or  pop-up  menus  and 
have  standard  keyboard  bindings.  Access  to  clipboard  transfer  shall  be  provided  in 
consistent  fashion  throughout  an  application. 

9.  Keyboard  accelerators  shall  be  available  to  perform  other  editing  operations  (e.g.,  Clear, 
Delete). 

10.  Users  shall  be  capable  of  viewing  the  clipboard  contents  and  shall  be  informed  when  they 
cut/copy  an  object  of  excessive  size  for  the  clipboard. 

11.  Cut  operations  shall  be  performed  by  the  following:  Selecting  Cut,  <Ctrl>  +  <X>,  and 
<Shift>  +  <Delete>). 

12.  Cut  shall  clear  the  previous  contents  of  the  clipboard,  store  a  copy  of  the  source  object  in 
the  clipboard,  and  remove  the  source  object  from  the  window. 

13.  If  the  cut  object  is  a  graphic,  the  space  where  the  graphic  object  was  previously  located 
shall  be  left  blank.  If  the  cut  object  is  text,  the  remaining  text  shall  be  compressed  in  the 
text  widget. 

14.  Copy  shall  clear  the  previous  contents  of  the  clipboard  and  store  a  copy  of  the  source 
object  in  the  clipboard;  the  source  object  shall  stay  in  its  original  location. 

15.  Copy  operations  shall  be  performed  by  the  following:  selecting  Copy,  <Ctrl>  +  <C>, 
<Ctrl>  +  <lnsert>). 

16.  Paste  shall  duplicate  the  object  in  the  clipboard  to  a  new  location. 

17.  Selecting  Paste,  <Ctrl>  +  <V>  and  <Shift>  +  <lnsert>)  shall  perform  a  paste  operation. 

18.  If  the  clipboard  content  is  text,  paste  shall  copy  the  clipboard  contents  to  the  location  of 
text  cursor  and  existing  text  appears  to  the  left  of  cursor.  If  existing  text  is  selected,  paste 
shall  copy  the  clipboard  contents  to  the  location  of  the  selected  text  and  remove  the 
selected  text.  The  pasted  object  shall  remain  in  the  clipboard  until  another  object  is 
cut/copied. 

19.  If  the  clipboard  content  is  graphic,  paste  shall  copy  the  clipboard  contents  to  the  pointer 
location  in  a  window  with  input  focus.  The  pasted  object  shall  remain  in  the  clipboard 
until  another  object  is  cut/copied  into  it. 
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20.  A  Copy  Link  entry  in  the  Edit  menu  shall  be  used  to  place  a  link  in  the  clipboard  to 
selected  elements  of  the  target  component  so  that  the  link  can  be  placed  in  a  destination 
by  subsequent  use  of  the  Paste  or  Paste  Link. 


Source 

CSFAB,  TBM,  MS1472F. 

Discussion 

The  clipboard  transfer  technique  transfers  an  object  selection  from  a  source  to  the  clipboard  and 

then  from  the  clipboard  to  the  destination. 

12.4.3  Primary  transfer 

1 .  Primary  transfer  operations  shall  include  primary  copy,  primary  move,  and  primary  link. 

2.  A  primary  transfer  operation  can  be  invoked  from  Pull  Down  or  Pop-up  Menus  and  have 
standard  keyboard  bindings.  Access  to  primary  transfer  shall  be  provided  in  consistent 
fashion  throughout  an  application. 

3.  Primary  transfers  shall  also  be  invoked  using  the  T  button. 

4.  The  default  operation  for  primary  transfer  using  the  T  button  is  copy. 

5.  In  an  editable  collection,  a  Primary  Copy  is  performed  by  the  following:  T  button  click, 
<Ctrl>  +  T  button  click,  and  <Alt>  +  <Ctrl>  +  <lnsert>. 

6.  In  an  editable  collection,  a  Primary  Move  is  performed  by  the  following:  <Shift>  +  T 
button  click  and  <Alt>  +  <Shift>  +  <Delete>. 

7.  In  an  editable  collection,  a  Primary  Link  is  performed  by  the  following:  <Ctrl>  +  <Shift> 
+  T  button  click. 

8.  Editing  commands  (such  as  move,  copy,  and  delete)  shall  be  provided  for  adding, 
inserting,  or  deleting  text/program  segments. 
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Source 


TBM,  MS1472F. 

Discussion 

The  primary  transfer  technique  transfers  the  primary  selection  directly  to  a  destination  without 

using  the  clipboard  for  immediate  storage  of  data. 

12.4.4  Quick  transfer 

1.  The  quick  transfer  operations  of  quick  copy,  quick  cut,  and  quick  link  are  available. 

2.  Quick  transfers  shall  be  invoked  using  the  <Alt>  +  T  button. 

3.  The  default  operation  for  quick  transfer  using  the  T  button  is  copy. 

4.  Text  components  must  support  quick  transfer. 

5.  If  quick  transfer  is  supported,  <Alt>  +  T  button  motion  or  <Alt>  +  <Ctrl>  +  T  button 
motion  must  temporarily  select  elements  in  the  specified  range  and,  on  release,  must  copy 
them  to  the  insertion  position  of  the  destination  component. 

6.  If  quick  transfer  is  supported,  <Alt>  +  <Shift>  +  T  button  motion  must  temporarily  select 
elements  in  the  specified  range  and,  on  release,  must  move  them  to  the  insertion  position 
of  the  destination  component. 

7.  If  quick  transfer  is  supported,  <Alt>  +  <Ctrl>  +  <Shift>  +  T  button  motion  must 
temporarily  select  elements  in  the  specified  range  and,  on  release,  must  place  a  link  to 
them  at  the  insertion  position  of  the  destination  component. 


Source 

TBM. 

Discussion 

A  quick  transfer  technique  allows  the  user  to  indicate  a  range  of  objects  (called  a  secondary 
selection)  that  are  transferred  to  the  destination  component. 

12.4.5  Drag  transfer  (drag  and  drop) 

1.  A  drag  and  drop  operations  shall  be  executed  by  pressing  the  primary  button  while 
pointing  to  an  object,  moving  the  input  device  while  holding  the  button  down,  and  then 
releasing  the  button  at  the  destination. 

2.  The  default  transfer  operation  shall  be  move. 
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Figure  7:  Drag  transfer  (drag  and  drop). 

3.  <Cancel>,  or  equivalent,  shall  cancel  a  drag  operation  and  return  the  object  being 
dragged  to  the  original  location. 

4.  Elements  moved  within  a  component  shall  remain  selected  after  they  have  been  moved. 

5.  Dragging  a  set  of  selected  elements  shall  drag  the  entire  collection. 

6.  Dragging  in  overlapping  elements  shall  occur  on  the  highest  draggable  element  in  the 
stack. 

7.  The  pointer  shape  shall  change  to  a  drag  icon  during  the  drag  operation  and  then  back  to 
pointer  at  the  completion  of  the  operation. 

8.  The  drag  icon  shall  contain  a  source  indicator  and  may  contain  operations  and  state 
indicators. 

9.  When  users  must  repeatedly  move  objects  by  means  of  a  drag  transfer  action  and  the  drag 
destination  is  to  the  same  or  a  default  location,  redundant  transfer  methods  shall  be  used. 
Redundant  transfer  methods  shall  include  the  capability  to  drag  a  set  of  selected  objects 
or  double-click  on  an  object  as  a  command  accelerator  for  the  drag  action. 

10.  A  drag  move  operation  shall  be  executed  by  holding  down  <Shift>  while  dragging  the 
object  using  the  T  button.  If  no  modifier  key  is  used  (that  is,  just  the  T  button  is  pressed 
on  an  object)  the  default  operation  is  a  move. 

11.  A  drag  copy  operation  shall  be  executed  by  holding  down  <Ctrl>  while  dragging  the 
object  using  the  T  button. 


Source 

TBM,  MSWUE. 

Discussion 

Movable  or  copyable  text  and  objects  shall  be  able  to  be  moved  or  copied  to  a  new  location  by 
using  the  pointer  and  the  drag  function. 

G2.  MSWUE  describes  variants  of  the  drag  and  drop  transfer  operation.  The  variants  include 
defining  the  transfer  operations  as  copy  or  link  or  destination-specific  commands  such  as  print  or 
send  to.  These  variants  add  undue  complexity  to  a  CCS  OM1  and  should  not  be  used. 
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12.5  Interactive  Control 


12.5.1  Object-action  selection 

1.  Users  shall  first  select  an  object,  and  then  they  shall  select  an  action  to  perform  on  that 
object. 

12.5.2  User  control  of  interaction 

1 .  Applications  shall  execute  an  action  only  in  response  to  explicit  user  input. 

2.  Users  may  take  actions  that  will  interrupt  or  terminate  a  process. 

Source 

TBM,  D1SA. 

12.5.3  Immediate  feedback 

1.  Control  feedback  responses  to  correct  user  input  shall  consist  of  changes  in  state  or  value 
of  those  display  elements  which  are  being  controlled  and  shall  be  presented  in  an 
expected  and  logically  natural  form 

2.  When  users  take  an  action,  there  shall  be  an  immediate  and  visible  response  to  the  action. 

3.  A  visible  response  shall  occur  even  if  the  result  cannot  be  displayed  immediately. 

4.  An  application  shall  provide  visual  cues  that  indicate  when  it  can  accept  input,  when  it  is 
temporarily  unavailable,  and  when  it  is  unavailable  during  extended  processing. 

5.  The  appearance  of  an  object  shall  indicate  its  availability. 

6.  If  an  operation  requires  several  actions,  users  shall  be  prompted  with  the  actions  to  take. 

7.  Applications  shall  ignore  user  actions  made  during  periods  when  input  cannot  be 
accepted. 

8.  The  pointing  device  and/or  the  keyboard  shall  be  disabled  when  input  may  be  destructive. 

9.  Although  an  application  shall  not  allow  users  to  override  disabling,  users  shall  be  able  to 
stop  a  process  if  desired  (e.g.,  by  selecting  a  cancel,  or  equivalent,  push  button). 

10.  The  current  value  of  any  parameter  or  variable  with  which  the  user  is  interacting  shall  be 
displayed. 


Source 

TBM,  D1SA,  MS1472F. 
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12.5.4  System  response  time 


1 .  System  response  times  shall  be  consistent  with  operational  requirements. 

2.  Required  user  response  times  shall  be  compatible  with  required  system  response  time. 

3.  Required  user  response  times  shall  be  within  the  limits  imposed  by  the  total  user  tasking 
expected  in  the  operational  environment. 

4.  The  system  shall  give  warning  information  when  a  command  is  invoked  when  that 
command  will  be  time  consuming  or  expensive  to  process. 

5.  System  response  shall  be  within  .2  seconds  of  user  action;  display  shall  take  no  more  than 
.5-10  seconds. 

6.  Requests  for  new  displays  may  take  between  2-10  seconds  if  an  operation  requires 
extensive  processing.  Timing  shall  begin  from  the  time  of  a  user  action  to  the  time  that  a 
fully  populated  display  is  presented. 

7.  Error  feedback  shall  be  provided  to  users  within  2  seconds  of  the  time  error  was  detected. 

8.  When  a  user  request  takes  more  than  2  seconds  to  process,  the  pointer  shape  shall  change 
to  an  hourglass. 

9.  When  response  to  a  user  request  takes  5-15  seconds  to  process,  an  animated  cursor  shall 
be  presented  to  show  progress. 

10.  When  response  to  a  user  request  will  take  15  seconds  to  1  minute  to  process,  a  message 
window  shall  be  displayed  immediately  informing  the  user  that  processing  is  ongoing. 

11.  As  a  matter  of  operational  necessity,  all  processing  must  be  able  to  be  interrupted  by  the 
users. 

12.  For  delays  exceeding  60  seconds,  a  countdown  display  shall  show  delay  time  remaining. 

13.  Where  system  overload  or  other  system  conditions  will  result  in  a  processing  delay,  the 
system  shall  acknowledge  the  data  entry  and  provide  an  indication  of  the  delay  to  the 
user.  If  possible,  the  system  shall  advise  the  user  of  the  time  remaining  for  the  process  or 
of  the  fraction  of  the  process  completed. 

14.  Maximum  system  response  times  for  real-time  systems  (e.g.,  fire  control  systems, 
command  and  control  systems)  shall  not  exceed  the  values  presented  in 
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Table  3:  Response  time  definitions 


System  interpretation 

Response  time  definition 

Time 

(secs) 

Key  response 

Key  depression  until  positive  response,  e.g.,  “click” 

.1 

Key  print 

Key  depression  until  appearance  of  character 

.2 

Page  turn 

End  of  request  until  first  few  lines  are  visible 

1.0 

Page  scan 

End  of  request  until  text  begins  to  scroll 

.5 

XY  entry 

From  selection  of  field  until  visual  verification 

.2 

Function 

From  selection  of  command  until  response 

2.0 

Pointing 

From  input  of  point  to  display  point 

.2 

Sketching 

From  input  of  point  to  display  of  line 

.2 

Local  update 

Change  to  image  using  local  data  base,  e.g.,  new 
menu  list  from  display  buffer 

.5 

Host  update 

Change  where  data  is  at  host  in  readily  accessible 
form,  e.g.,  a  scale  change  of  existing  image 

2.0 

File  update 

Image  update  requires  an  access  to  a  host  file 

10.0 

Inquiry  (simple) 

From  command  until  display  of  a  commonly  used 
message 

2.0 

Inquiry  (complex) 

Response  message  required  seldom  used 
calculations  in  graphic  form 

10.0 

Error  feedback 

From  entry  of  input  until  error  message  appears 

2.0 

17.  During  start-up,  the  system  shall  display  a  message  window  indicating  its  unavailability, 
change  the  pointer  shape  to  an  hourglass  or  watch,  and  disable  input  from  the  pointing  device 
and  keyboard. 


18.  When  the  system  is  ready,  the  message  window  shall  disappear,  the  pointer  shall  return  to  a 
standard  shape,  and  the  input  shall  be  enabled. 
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19.  If  appropriate,  the  system  shall  display  status  messages  (e.g.,  response  time  and 
unavailability). 

20.  If  computer  processing  time  requires  delay  of  concurrent  user  inputs,  and  no  keyboard  buffer 
is  available,  keyboard  lockout  shall  occur  until  the  computer  can  accept  the  next  transaction. 
An  alert  shall  be  displayed  to  indicate  to  the  user  that  lockout  has  occurred. 

21.  When  the  computer  is  ready  to  continue  after  a  response-time  induced  keyboard  lockout,  a 
signal  to  so  indicate  shall  be  presented  (e.g.,  the  cursor  changes  back  to  normal  shape). 

22.  When  keyboard  lockout  has  occurred,  the  user  shall  be  provided  with  a  capability  to 
terminate  a  transaction  that  has  resulted  in  an  extended  lockout.  Such  capability  shall  act  like 
an  undo  command  that  stops  ongoing  processing  and  does  not  reset  the  computer  thereby 
losing  prior  processing. 

Source 

TBM,  D1SA,  MS1472F,  UCA. 

Discussion 

The  system  should  always  keep  users  informed  about  what  is  going  on  by  using  appropriate 
feedback.  The  Microsoft  Copy  dialog  box  presented  below  (see  Figure  8)  illustrates  how  the 
system  can  provide  feedback  during  a  time-intensive  function.  Note  that  the  progress  bar  and  time 
indicate  the  expected  length  for  executing  the  actions  as  well  as  the  ability  to  cancel  the  operation. 
In  addition,  the  dialog  box  can  provide  a  simple  animation  to  let  the  user  know  that  the  action  is 
being  carried  out. 


Animation 


Progress 

bar 


Cancel 

button 


Time 

remaining 


Figure  8:  Example  of  system  feedback. 

G 1 1 :  If  an  exemption  to  this  guideline  is  necessary,  and  a  process  is  included  that  cannot  be 
interrupted  by  the  user  then  the  following  guidance  from  TBM  shall  be  followed:  When  response 
to  a  user  request  will  exceed  1  minute  and  processing  will  prevent  the  user  from  further 
interaction  until  the  process  is  complete  then  a  confirmation  shall  be  presented  prior  to  the 
process  being  initiated.  The  confirmation  message  shall  inform  the  user  of  the  expected  duration 
of  the  process  and  that  the  user  will  be  unable  to  continue  until  the  process  is  complete. 
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12.5.5  Error  detection 


1.  The  application  shall  not  execute  a  user-requested  action  that  is  considered  invalid. 
Instead,  an  error  message  shall  be  displayed. 

2.  A  capability  shall  be  provided  to  facilitate  detection  and  correction  of  errors  after  keying 
in  but  before  entering  the  information  into  the  system.  While  errors  shall  be  detected 
early,  error  checking  shall  occur  at  logical  data  entry  breaks  (e.g.,  at  the  end  of  data  fields 
rather  than  character-by-character)  in  order  to  avoid  disrupting  the  user. 

3.  User  errors  shall  be  minimized  by  use  of  software  checks  of  user  entries  for  validity  of 
item,  sequence  of  entry,  completeness  of  entry,  and  range  of  value. 

4.  When  users  make  multiple  errors  with  a  single  action,  they  shall  be  notified  of  each  error. 
Multiple  occurrences  of  the  same  error  shall  not  appear  in  separate  windows. 

5.  When  users  make  multiple  errors  with  a  single  action,  they  will  be  provided  with  an 
immediate  description  of  the  error  and  the  total  number  of  additional  errors  detected,  as  in 
a  word  processing  spell  checker.  There  shall  be  some  means  for  the  user  to  request  and 
correct  sequential  display  of  error  messages. 

6.  To  prompt  for  correction  of  an  error  in  stacked  commands,  the  system  shall  display  the 
stacked  sequence  with  the  error  highlighted.  Where  possible,  a  procedure  shall  be 
provided  to  correct  the  error  and  salvage  the  stack. 

7.  A  computer-detected  error,  as  well  as  the  error  message,  shall  be  continuously  displayed 
until  the  error  is  corrected. 

8.  When  an  error  is  repeated,  feedback  shall  show  that  an  attempted  correction  was 
processed. 

9.  Users  shall  be  required  to  correct  only  an  invalid  action  and  not  to  repeat  the  entire 
sequence.  The  system  shall  permit  correction  of  individual  errors  without  requiring  re¬ 
entry  of  correctly  entered  commands  or  data  elements. 

10.  After  making  a  correction  users  shall  be  able  to  execute  the  same  action  for  re-entry  that 
was  used  for  the  original  entry. 

1 1 .  Error  messages  shall  first  state  the  problem  followed  by  a  statement  of  appropriate 
solutions. 


Source 


TBM,  MS1472F,  UCA. 

12.5.6  Undo  capability 

1.  Users  shall  be  allowed  to  undo  the  most  recent  selection  or  action  unless  the  selection  or 
action  required  explicit  destruction. 

2.  Users  shall  be  allowed  to  execute  a  multi-level  undo. 
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3.  In  addition  to  being  able  to  undo  commands,  users  shall  be  able  to  deselect  objects,  return 
an  object  to  its  prior  state  before  an  action  was  executed,  and  retrieve  information  that 
was  removed  from  the  screen. 

4.  Users  shall  be  allowed  to  re-do  the  most  recent,  or  specified  “undone”  transaction. 

5.  Irreversible  actions  (actions  that  cannot  be  undone)  shall  be  labelled  and  clearly  separated 
from  actions  that  are  reversible. 

6.  If  an  action  cannot  be  labelled  as  irreversible,  the  user  shall  be  presented  with  a  warning 
and  asked  to  confirm  the  irreversible  action. 

7.  When  an  undo  option  is  provided,  the  wording  shall  change  dynamically  to  reflect  the 
action  that  can  be  undone.  The  undo  option  shall  always  begin  with  Undo.  For  example, 
if  the  most  recently  executed  action  is  a  cut,  the  undo  option  shall  be  worded  Undo  Cut. 


Source 

CSFAB,  TBM,  MS1472F,  MSWUE. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  ease  and  consistency  of  navigation  of  the  interface. 

Operator  performance: 

•  Objective  assessment  of  use  and  usefulness  of  tools  for  navigating  through  the  OMI  through 
usability  testing. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  perceptions  of  usability,  utility,  and 
consistency  of  tools  for  navigating  through  the  OMI  and  ESS. 

Relationship  to  other  guidelines 

10  Windows 

1 1  Window  design  guidance 

15  Windows  states,  components,  and  operations 
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13  Controls 


13.1  Control  characteristics 

1.  All  of  the  types  of  controls  in  a  window  shall  be  identifiable  solely  based  on  their 
appearance. 

2.  All  controls  with  the  same  function  shall  have  the  same  appearance. 

3.  Text/graphics  in  a  window  shall  be  clearly  different  in  appearance  from  standard  controls. 

4.  Controls  performing  similar  or  related  functions  shall  be  physically  grouped  together. 

5.  Grouped  controls  shall  be  framed  and  shall  be  clearly  labelled  to  indicate  the  functions 
they  perform. 

6.  Controls  that  are  temporarily  unavailable  shall  be  dimmed  and  shall  not  be  available  for 
selection. 

7.  Controls  that  are  never  available  to  users  shall  not  appear  in  a  window. 

8.  Lines  surrounding  a  group  of  controls  shall  follow  the  look  and  labelling  of  Microsoft 
Windows  styles. 


Source 

CSFAB,  TBM,  D1SA,  UCA. 

Discussion 

Gl.  Generally  all  selectable  objects  have  a  three-dimensional  appearance  (i.e.,  appropriate 
shadowing)  and  all  non-selectable  or  display-only  objects  are  not  three-dimensional  in 
appearance. 

13.2  Control  actions 

1.  Control  actions  shall  be  minimized,  consistent,  make  minimal  memory  demands  of  the 
user,  and  be  sufficiently  flexible  to  adapt  to  different  user  needs. 

2.  Very  frequent  or  safety-critical  tasks  shall  be  identified  and  shall  be  accomplished  with  a 
single  operator  action  such  as  a  keystroke  or  button  press. 

3.  Frequent  or  critical  tasks  shall  be  identified  and  shall  be  accomplished  with  no  more  than 
three  operator  actions  (keystrokes,  button  presses,  etc.) 

4.  User  acceptance  of  stored  data  or  defaults  shall  be  possible  by  a  single  confirming 
keystroke. 
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5.  Control  actions  to  be  selected  from  a  discrete  set  of  alternatives  shall  have  those 
alternatives  displayed  prior  to  the  time  of  selection. 

6.  User  control  inputs  shall  result  in  a  positive  feedback  response  displayed  to  indicate 
performance  of  requested  actions. 

7.  If  a  default  button  is  defined  it  shall  be  non-destructive.  A  destructive  action  is  an  action 
that  cannot  be  reversed  (e.g.,  missile  launch),  or  cannot  be  routinely  reversed  without 
extensive  or  special  procedures  (e.g.,  un-erase  a  file),  and  therefore  shall  be  preceded  by  a 
user  confirmation  in  a  dialog  box.  The  confirmation  shall  usually  be  the  “OK”  button  (or 
equivalent),  unless  the  action  is  destructive  wherein  the  “Cancel”  button  shall  be  used  as 
the  default.  The  default  can  only  be  used  when  the  default  button  is  active. 


Source 

CSFAB,  MS1472F. 

Discussion 

G2.  Examples  of  frequent  or  safety  critical  tasks  for  Halifax-Class  CCS  operations  include 
hooking  tracks  or  changing  the  range  in  the  tactical  display. 

G7.  The  implication  is  that  an  action  such  as  a  missile  launch  requires  a  second,  confirming 
action.  In  hardware  implementations  the  second  action  is  usually  opening  the  trigger  guard.  The 
design  of  the  confirming  action  must  consider  the  entire  operational  task. 

13.3  Control  areas 

1.  The  QABs  (or  their  functional  equivalent)  shall  be  located  on  the  same  monitor  as  the 
tactical  picture  so  as  to  reduce  eye  and  hand  movements. 

2.  The  display  shall  include  visual  affordance  for  the  operators. 

3.  Controls  for  operations  that  are  potentially  destructive  shall  not  be  co-located  with 
frequently  used  or  confusable  controls. 

4.  Frequently  used  and  critical  controls  shall  be  located  at  anchor  points  within  the  display 
or  shall  be  organized  in  order  of  priority. 

5.  Controls  shall  have  a  large  active  area  so  that  the  operator  does  not  have  to  access  a  small 
target  area. 

6.  Direct  access  to  the  desired  levels  of  controls  shall  be  obtained  without  requiring 
intervening  steps. 

7.  Controls  shall  be  sufficiently  large  to  be  accessed  easily  under  expected  Maritime 
conditions. 
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UCA. 


Discussion 

If  the  operator  must  search  for  a  control  then  the  operator’s  attention  is  devoted  to  the  interface 
rather  than  the  operational  task.  New  layouts  and  designs  should  provide  good  visual  affordance 
to  improve  navigation  within  the  tactical  controls.  New  controls  should  also  address  the  sequence 
with  which  operators  access  the  functions  and  should  support  the  operational  task  flow. 

13.4  Action  icons 

1.  Action  icons  shall  have  unique  graphic  images  so  that  users  recognize  the  action 
performed.  Action  icons  shall  not  conflict  with  action  icons  that  are  already  defined. 

2.  Action  icon  graphics  in  an  application  shall  be  consistent  with  icons  in  other  applications 
in  the  system  and  shall  be  consistent  with  the  icons  that  are  already  defined. 

3.  Developers  shall  use  a  short  text  label  in  addition  to  a  graphic  for  action  icons.  This  is 
especially  important  if  the  function  being  represented  is  highly  abstract. 

4.  Colours  used  in  images  in  action  icons  shall  be  similar  to  other  system  colours  and  used 
in  a  consistent  manner. 

5.  Graphics  for  action  icons  representing  opposite  actions  shall  be  designed  to  mirror  each 
other. 

6.  Graphics  shall  be  presented  in  a  common  style  and  oriented  consistently  within  the 
button. 

7.  An  action  icon  shall  be  large  enough  for  a  user  to  see  and  understand  the  graphic  and  text 
label.  An  action  icon  shall  also  be  large  enough  to  be  easily  selectable  via  the  pointing 
device. 

8.  Action  icons  shall  be  grouped  by  task  relevance  or  frequency  of  use. 

9.  Action  icons  shall  duplicate,  but  do  not  replace  selections  in  a  pull-down  menu. 

Source 

TBM. 
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Discussion 


Action  icons  provide  unique  graphic  images  that  enable  the  user  to  recognize  the  action  to  be 
performed.  Table  4  depicts  some  of  the  common  action  icons  that  exist  across  Microsoft 
applications. 


Table  4:  Examples  of  action  icons. 


Icon 

Term 

Action  Performed 

D 

New 

Opens  a  new  document  within  the  application. 

& 

Open 

Launches  the  Open  dialog  box  in  order  to  open  an 
existing  document. 

y 

Save 

Saves  the  current  document. 

m 

Print 

Prints  the  current  document. 

a 

Print  Preview 

Opens  the  preview  window  so  that  the  print  version 
of  the  document  can  be  viewed  on-line. 

it 

Cut 

Removes  an  object  from  a  window  and  stores  it  on 
the  clipboard 

m 

Copy 

Duplicates  an  object  to  the  clipboard  without 
deleting  it  from  the  window. 

ra, 

Paste 

Inserts  an  object  from  the  clipboard  into  a  window 
at  the  selected  location. 

o 

Undo 

Returns  an  object  to  its  state  prior  to  the  last 
operation  being  executed. 

o 

Redo 

Reverts  the  Undo  operation. 

X 

Delete 

Deletes  the  selected  object  from  the  window. 

B 

Bold 

Bolds  the  selected  text. 

S 

Italics 

Changes  the  selected  text  to  italics. 

G3.  An  ellipsis  (.  .  .)  is  used  to  indicate  that  a  push  button  or  menu  command  will  present  a 
dialog  box  when  selected.  Since  the  space  available  for  text  labels  on  action  icons  is  limited,  the 
ellipsis  may  be  eliminated  for  action  icons  only.  Text  labels  may  be  omitted  if  action  icons  are 
presented  in  a  palette  as  in  drawing  tools  for  graphics. 

13.5  Push  buttons 

13.5.1  General  push  button  characteristics 

1 .  Push  buttons  shall  be  used  to  initiate  an  action. 
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2.  Every  window  shall  provide  a  push  button  (e.g.,  Close  and  Cancel)  that  allows  users  to 
dismiss  the  window. 


Source 


CSFAB,  TBM. 


13.5.2  Appearance 

1.  Push  buttons  shall  be  the  same  width  within  a  grouping  of  vertical  buttons.  A  group  of 
buttons  that  are  horizontally  arranged  do  not  require  equal  button  width. 

2.  Push  buttons  shall  be  wide  enough  to  display  the  longest  button  label  or  largest  action 
icon. 

3.  Button  width  shall  be  made  larger  if  window  space  is  available. 

4.  Buttons  that  are  used  frequently  shall  be  as  large  as  possible. 

5.  Push  button  minimum  size  shall  be  as  follows  (measured  inside  the  traversal  highlight): 

■  Text  Size.  Text  size  shall  be  sufficiently  large  that  text  is  readable  with  a  margin 
surrounding  the  text  as  indicated  in  MSWUE. 

■  Icon  Size.  Icons  shall  be  sufficiently  large  so  that  the  icon  can  be  identified  and 
discriminated  from  other  icons;  at  least  0.26  inches  height  and  width. 

■  Empty  button:  at  least  0.20  inches  in  both  height  and  width. 

■  QAB  size.  A  QAB  button  shall  be  sufficiently  large  for  three  lines  of  readable 
text  (8-10  char,  per  line)  or  two  lines  of  text  plus  a  colour  bar;  at  least  0.70 
inches  in  both  height  and  width. 

6.  All  push  buttons  in  an  action  area  of  a  dialog  window  shall  be  the  same  size.  An 
exception  to  this  design  rule  may  occur  in  order  to  accommodate  a  push  button  label  or 
graphic  that  is  significantly  longer  that  the  other  push  button  labels  in  the  window. 


Equal 

button  sizes 


Figure  9:  Example  of  Equal  and  Unequal  Button  Sizes. 
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7.  The  colour  of  the  face  of  buttons  shall  be  one  colour  when  the  button  is  pressed  and  a 
different  colour,  or  shade,  when  the  button  is  not  pressed.  The  colour  differences  shall  be 
sufficiently  distinct  to  be  easily  discriminated  by  the  operator  and  shall  be  consistent  with 
the  colour  guidelines  in  this  style  guide. 


Source 

CSFAB,  TBM,  MSWUE,  UCA. 

Discussion 

G5.  See  MSWUE  (Chapter  14)  for  a  detailed  presentation  of  spacing  and  positioning  of  OMI 

interface  items.) 

G7.  This  guideline  was  added  as  a  result  of  the  review  of  the  COMDAT  TD. 

13.5.3  Push  button  labels 

1 .  Push  button  labels  shall  be  large  enough  for  easy  reading  at  minimum  over-the-shoulder 
viewing  distances  (i.e.,  27  inches).  There  shall  be  enough  space  between  the  label  and  the 
rectangle  surrounding  it  so  that  the  label  will  not  restrict  the  legibility  or  visibility  of  the 
text  or  the  graphic  in  the  push  button. 

2.  Push  button  labels  shall  be  short  and  unambiguous  and  the  label  shall  be  mixed  case  with 
the  first  letter  of  each  word  capitalized  (book  title  capitalization). 

3.  If  push  button  actions  affect  different  objects,  their  labels  shall  reflect  what  each  affects. 

4.  Action  button  labels  shall  describe  the  action,  stated  in  active  voice,  taken  by  the 
application  when  the  action  button  is  selected  (e.g.,  Print,  Save,  Delete). 

5.  The  label  for  action  buttons  shall  describe  the  results  of  pressing  the  button  and  reflect  the 
action  that  will  be  taken  by  the  application  rather  than  the  user. 

6.  When  “All”  is  used  in  a  push  button  label,  there  shall  be  no  ambiguity  as  to  reference. 

7.  Push  button  labels  with  multiple  references  shall  include  the  name  of  the  object/element. 
For  example,  a  “Select  All”  button  for  map  symbols  is  better  labelled  “Select  All 
Symbols”  to  make  the  reference  clear. 

8.  Existing  vocabularies  shall  be  used  to  construct  push  button  labels  whenever  applications 
perform  actions  that  are  already  defined  elsewhere.  Before  creating  a  new  vocabulary,  it 
shall  be  determined  at  minimum  if  the  vocabulary  already  exists  in  the  following  sources, 
(these  sources  are  listed  in  order  of  precedence): 

-  MSWUE 

■  CSFAB 

-  TBM 

Other  references  shall  also  be  reviewed,  with  priority  given  to  CCS  style  guides,  to  avoid 
creating  duplicate  vocabularies. 
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Examples  of  these  vocabularies  (drawn  from  TBM)  include  the  following: 

■  Manipulating  Primary  Windows 

♦  Back 

♦  Close 

♦  Exit 

■  Manipulating  Files  and  Directories 

■  Delete 

■  Save  As 

■  Print 

■  Editing  Text  or  Graphics  Objects 

♦  Cut 

♦  Paste 

♦  Find 

■  Manipulating  Items 

♦  Delete 

♦  Edit 

♦  Sort 

■  Manipulating  Maps 

♦  Pan 

♦  Zoom 

♦  Centre  On 

9.  A  new  vocabulary  shall  be  created  as  needed  to  describe  actions  not  defined  in  the 
existing  guidance  documents. 

10.  When  new  vocabulary  is  used,  it  shall  describe  actions  not  listed  in  the  guiding 
documents. 

11.  If  a  new  action  is  created,  it  shall  be  a  verb,  stated  in  active  voice,  and  shall  describe  the 
action  that  will  occur  upon  selection  of  the  button. 

12.  A  more  specific  command  label  shall  be  substituted  for  Yes,  No,  and  OK  whenever 
possible  (e.g.,  Save,  Print). 

13.  OK  and  Yes  shall  not  be  the  label  for  the  default  button  if  the  action  executed  by  the 
button  is  potentially  destructive.  The  default  push  button  shall  have  an  extra  border 
around  it.  The  labels  for  accepting  an  action  shall  reflect  the  action  to  be  taken. 

14.  The  names  of  actions  shall  be  congruent  (e.g.,  save/delete,  on/off,  in/out). 

15.  The  same  vocabulary  shall  describe  the  same  action  throughout  the  application/system. 
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16.  Existing  icons  shall  be  used  whenever  applications  use  icons  that  are  already  defined 
elsewhere.  Before  creating  a  new  icon,  it  shall  be  determined  at  minimum  if  the  icon 
already  exists  in  the  following  references;  these  references  are  listed  in  order  of 
precedence.  Other  references  shall  also  be  reviewed,  with  priority  given  to  CCS  style 
guides,  to  avoid  creating  multiple  icons  to  convey  the  same  meaning. 

-  MSWUE 

■  CSFAB 

•  TBM 

17.  A  push  button  shall  have  an  ellipsis  (.  .  .)  if  selecting  it  results  in  another  window  (other 
than  a  help  window  or  a  confirmation  window)  being  displayed. 


Source 

CSFAB,  TBM,  MSWUE,  UCA. 

Discussion 

Gl.  TBM  indicates  that  the  labels  shall  be  large  enough  for  easy  reading  at  normal  viewing 

distances.  In  Canadian  Maritime  operations,  the  CCS  displays  are  often  needed  by  crewmembers 

that  are  not  seated  at  the  display.  Supporting  over-the -shoulder  reading  distances  benefits  over- 

the-shoulder  viewing  and  optimizes  the  visibility  for  the  operator  when  in  a  relaxed  posture. 

G8.  CSFAB,  MSWUE  and  TBM  each  provide  tables  of  existing  vocabularies. 

G9.  TBM  refers  to  specific  tables. 

G13.  For  example:  “Launch  Missile”  is  a  better  label  than  “Yes”  or  “OK”. 

G16.  CSFAB,  MSWUE  and  TBM  each  provide  tables  of  existing  icons. 

13.5.4  Push  button  organization 

1.  Buttons  within  sets  shall  be  sub-grouped  according  to  similar  functions.  A  subgroup  may 
contain  one  or  more  buttons. 

2.  A  set  of  buttons  that  supports  a  specific  task  sequence  shall  be  grouped  from  left  to  right 
and/or  from  top  to  bottom. 

3.  Push  buttons  shall  be  located  near  the  object(s)  they  affect. 

4.  Push  button  order  shall  use  the  following  common  labels  and  actions  and  applicable 
buttons  shall  appear  from  left  to  right  in  the  following  sequence:  Yes,  No,  OK,  Close, 
Apply,  Retry,  Stop,  Pause,  Resume,  Reset,  Cancel. 

5.  A  “Flelp”  button  shall  not  be  required  in  every  window.  The  button  to  access  help  shall  be 
in  accordance  with  Microsoft  Window  conventions  (e.g.,  a  “?”  button  to  the  left  of  the 
“Close”  button.) 

6.  The  order  of  push  buttons  in  modal  windows  shall  be:  OK,  Cancel. 
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7.  The  order  of  push  buttons  in  modeless  windows  shall  be:  OK,  Apply,  Cancel  or  OK, 
Apply,  Reset,  Cancel. 

8.  Application-specific  push  buttons  shall  be  ordered  left  to  right  based  on  the  sequence  of 
use,  with  the  most  often  used  push  button  on  the  left. 

9.  Buttons  for  positive  actions  shall  be  at  the  left,  and  followed  by  negative/destructive  and 
cancelling  actions. 

10.  Push  buttons  shall  appear  in  the  same  order  in  windows  throughout  the  application. 

11.  Push  buttons  related  to  overall  window  functionality  (e.g.,  OK,  Cancel)  shall  be  located  at 
the  bottom  of  the  window  in  a  row  that  is  centred  horizontally  across  the  window. 


Source 

CSFAB,  TBM. 

Discussion 

G4.  Yes,  No,  and  OK  should  be  replaced  by  more  specific  command  labels  whenever 

possible. 

G1 1 .  Push  buttons  shall  appear  in  the  action  area  of  a  dialog. 

13.5.5  Activating  a  push  button 

1 .  The  S  button  on  the  pointing  device  shall  be  used  to  activate  a  push  button. 

2.  The  <Space>  key  (and  <Select>  if  available)  shall  select  a  push  button  from  the  keyboard 
when  the  location  cursor  is  on  a  push  button. 

3.  When  a  push  button  is  selected,  it  shall  highlight  and  the  action  it  represents  shall  be 
executed. 

4.  Push  buttons  shall  be  activated  by  single  clicks  of  the  pointing  device  only.  A  double 
click  action  shall  not  be  used  on  a  push  button. 


Source 

TBM. 

13.5.6  Default  push  buttons 

1 .  A  default  push  button  may  be  available  in  dialog  windows  of  an  application.  A  default 
push  button  shall  be  indicated  by  an  extra  border  around  it  (see  MSWUE  for  design 
details). 
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Default  push 
button 


Figure  10:  Example  of  the  default  push  button  on  a  MS  warning  message  window. 


2.  The  same  push  button  shall  be  the  default  whenever  a  dialog  window  is  initially 
displayed. 

3.  The  default  push  button  in  a  window  may  vary  depending  on  the  object  with  keyboard 
focus  in  a  window. 

4.  Default  designation  shall  move  with  the  location  cursor  during  keyboard  navigation 
through  push  buttons. 

5.  Default  designation  shall  return  to  the  original  button  when  focus  leaves  the  push  button 
group. 

6.  OK  and  Yes  shall  not  be  the  default  push  buttons  if  the  action  executed  by  the  button  may 
be  destructive. 

7.  Whenever  possible,  the  default  action  shall  be  reversible. 

8.  Apply  shall  be  the  default  action  in  modeless  windows  that  are  displayed  for  multiple 
actions. 


Source 

TBM,  MSWUE,  UCA. 

13.6  Toolbars 

Toolbars  are  on-screen  menus  that  use  icons  instead  of  words  to  represent  functions.  Using  icons 
instead  of  words  allows  many  more  options  to  be  provided  in  the  same  display  area.  The  fact  that 
the  toolbar  is  always  present  on-screen  allows  quick  access  to  options. 
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I Menu  bar 


I  Standard  toolbar 
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Formatting  toolbar 


Figure  11:  Example  of  docked  toolbars.  It  illustrates  the  horizontal  configuration  for  the 
Standard  and  Formatting  toolbars  that  are  typically  docked  at  the  top  of  the  application  window 
for  Microsoft  Word.  To  assist  with  their  identification,  labels  for  each  action  icon  in  the  toolbars 
in  Microsoft  Word  are  presented  via  the  ToolTips  functionality. 


Figure  12:  Example  of  a  Floating  Toolbar.  It  illustrates  a  floating  configuration  for  the  Microsoft 
Standard  toolbar  presented  above.  In  this  example,  the  shape  of  the  toolbar  has  been  changed  to 
align  the  buttons  across  two  rows  as  opposed  to  one. 

13.6.1  Toolbar  general  characteristics 

1 .  Only  commonly  used  options  shall  be  placed  in  a  toolbar. 

2.  Toolbars  shall  be  placed  directly  below  the  menu  bar  or  may  be  converted  into  their  own 
window  and  placed  at  any  allowable  display  location  by  the  operator  (see  Figure  1 1  and 
12). 

3.  Specific  toolbars  shall  hold  groups  of  options  that  are  needed  for  a  specific  task  (e.g., 
drawing  tools)  (see  Figure  11). 

4.  Toolbars  shall  provide  a  redundant  means  of  accessing  a  function  (all  functions  in  a 
toolbar  shall  also  be  available  in  the  menus). 

5.  All  the  action  icons  in  a  palette  or  a  toolbar  shall  be  the  same  size  (see  Figure  11). 

6.  When  an  icon  in  the  toolbar  is  pre-selected,  the  pull-down  menu  name  of  that  command 
shall  be  displayed  below  the  icon  as  a  Tool  Tip.  This  is  a  form  of  help  that  allows  users  to 
become  familiar  with  the  icons  and  shall  be  able  to  be  disabled  once  the  user  becomes 
fully  familiarized  with  the  icons. 


Source 

CSFAB,  TBM. 

Discussion 
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G6.  This  concept  is  described  in  detail  in  MSWUE  as  Tool  Tips.  Design  details  and  timing 
information  are  provided  in  MSWUE. 

13.6.2  Toolbar  order  and  grouping 

1 .  Each  toolbar  shall  have  a  hierarchical  order,  such  that  if  multiple  toolbars  are  displayed 
they  will  be  ordered  consistently  on  the  display. 

2.  More  commonly  used  toolbars  shall  be  placed  on  top  of  less  commonly  used  toolbars 
with  the  main  toolbar  being  located  directly  under  the  pull-down  menu  bar. 

3.  Icons  shall  be  ordered  in  groups  with  spaces  between  icon  groups  (e.g.,  all  editing  icons 
would  be  together  and  delimited  by  a  space  and  separator  line  followed  by  all  formatting 
icons.) 


Source 

CSFAB. 

Discussion 

G3.  See  MSWUE  for  design  details. 

13.6.3  Toolbar  windows 

1 .  All  toolbars  shall  be  able  to  float  by  selecting  any  region  inside  the  toolbar  and  moving  it 
to  another  display  location. 

2.  The  floating  toolbar  window  shall  then  be  able  to  be  closed,  sized,  or  moved  to  any  other 
display  location  like  a  normal  window. 

3.  If  the  toolbar  window  is  moved  back  over  the  pull-down  menu  or  another  toolbar,  the 
toolbar  window  shall  be  converted  back  into  a  standard  toolbar  and  placed  under  the  pull¬ 
down  menu  bar  in  its  toolbar  hierarchy. 

4.  Toolbar  windows  shall  be  on  the  same  visual  layer  as  their  parent  application  and  shall 
have  shared  focus  with  their  application. 

5.  An  application  action  icon  palette  or  toolbar  shall  be  able  to  be  repositioned  or  removed 
from  the  window  if  desired  by  the  user. 

6.  A  palette  or  toolbar  displayed  in  its  own  window  containing  action  icons  shall  always 
remain  on  top  of  the  window  to  which  it  pertains. 


Source 

CSFAB,  TBM. 
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13.6.4  Toolbar  Icons 


1.  Action  icons  shall  be  presented  together  on  a  palette  or  toolbar.  A  toolbar  presentation 
places  action  icons  next  to  each  other  in  either  a  horizontal  or  a  vertical  alignment.  A 
palette  presentation  places  action  icons  in  a  matrix  alignment. 

2.  Application  action  icon  palettes  shall  appear,  by  default,  along  the  left  margin  of  the 
window.  Application  toolbars  shall  appear,  by  default,  beneath  the  menu  bar. 

3.  An  application  action  icon  palette  shall  contain  no  more  than  20  action  icons  and  an 
application  toolbar  shall  contain  no  more  than  30  action  icons. 

4.  If  numerous  or  non-standard  action  icons  are  used  a  command  or  an  abbreviated  form  of 
the  command  shall  be  placed  beneath  the  icon.  A  toolbar  presentation  of  action  icons 
shall  always  have  labels. 

5.  A  palette  presentation  is  generally  reserved  for  graphical  tools.  Since  the  graphics  on  the 
action  icon  resemble  the  graphics  produced,  text  labels  may  be  omitted  when  action  icons 
are  presented  in  a  palette.  Tool  tips  shall  be  employed  for  tools  in  a  palette  presentation. 

6.  An  action  icon  palette  and  toolbar  shall  support  navigation  and  selection  from  the 
keyboard. 
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Source 


TBM,  UCA. 

Discussion 

Option  buttons  are  called  radio  buttons  in  Motif  style  guides. 

G6.  This  shall  be  accomplished  by  the  same  means  as  any  push  button  activated  from  the 
keyboard. 

13.7  Option  buttons 

Option  buttons  allow  users  to  select  one  option  from  a  group  of  mutually  exclusive  options.  The 
option  buttons  illustrated  below  are  typically  found  on  the  Print  dialog  box  for  Microsoft 
applications  whereby  the  three  "Page  range"  options  allow  the  user  to  select  one  of  three  distinct 
settings  for  printing  the  document. 


Figure  13:  Example  of  option  buttons. 

Option  button  characteristics 

An  option  button  shall  be  used  to  select  one  option  from  a  group  of  mutually  exclusive 
options. 

One  option  button  must  be  selected  from  each  mutually  exclusive  group  at  all  times.  If  no 
selection  is  a  valid  option  then  a  choice  labelled  “None”  shall  be  provided. 

When  option  buttons  are  used,  they  shall  provide  a  sufficiently  large  target  to  be  easily 
operable  under  expected  Maritime  conditions. 

Option  button  indicators  shall  be  the  same  size  throughout  the  application. 

Option  buttons  shall  not  be  used  to  initiate  actions  or  open  dialog  windows. 

The  label  of  an  option  button  shall  define  the  state  set  by  the  user. 

The  label  text  shall  be  displayed  in  mixed  case  with  the  first  letter  of  the  option 
capitalized. 


13.7.1 

1. 

2. 

3. 

4. 

5. 

6. 
7. 
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8.  When  the  option  button(s)  are  selected  but  not  executed,  the  application  shall  not  save  the 
selection  and  the  option  button(s)  shall  return  to  their  original  state  when  the  window  is 
displayed. 


Source 

CSFAB,  TBM,  UCA. 

Discussion 

G3.  The  active  area  for  an  option  button  can  be  visually  enhanced  by  displaying  the  entire 
active  area  of  the  button  to  the  operators.  Even  advanced  users  tend  to  use  the  small  target  of  the 
option  button  graphic  rather  than  the  entire  active  area.  The  standard  option  button  size  presents 
too  small  a  target  to  be  used  for  Maritime  operations. 

13.7.2  Option  button  order  and  grouping 

1 .  Option  buttons  shall  be  arranged  in  vertical  groupings. 

2.  A  group  of  option  buttons  shall  provide  no  more  than  eight  alternatives  and  shall  include 
a  title  that  describes  the  type  of  information  being  presented. 


Source 

CSFAB,  TBM. 

Discussion 

Gl.  CSFAB  indicates  that  horizontal  groupings  may  be  used  if  space  requirements  so  dictate. 

13.7.3  Option  button  selection 

1 .  The  S  button  on  the  pointing  device  shall  be  used  to  select  an  option  button. 

2.  When  the  location  cursor  is  on  an  option  button  then  <Space>  (and  <Select>,  if  available) 
shall  select  an  option  button  from  the  keyboard. 

3.  When  an  option  button  is  selected,  it  shall  be  highlighted  and  any  other  selected  button  in 
that  option  box  group  shall  be  deselected. 

4.  If  an  option  button  is  in  a  window  with  a  default  action,  <Enter>  or  <Retum>  shall 
execute  the  default  action. 

5.  If  an  option  button  is  unavailable  for  selection,  its  label  shall  be  greyed  out  to  indicate  its 
unavailability. 


Source 

TBM. 
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13.8  Toggle  buttons 


Toggle  buttons  allow  users  to  alternate  between  two  states  for  a  given  object  using  a  single 
button.  For  example,  the  Show/Hide  button  on  a  toolbar  can  be  pressed  to  display  the  formatting 
symbols  in  a  Microsoft  Word  document.  For  the  "Show"  state,  the  button  remains  visually 
pressed  (left  figure  in  Figure  14)  until  the  user  clicks  the  button  again  and  reverses  the  setting  to 
the  "Flide"  state  (right  figure  in  Figure  14). 

0  IF  100O/  0  IT  100°' 

Figure  14:  Example  of  a  show/hide  toggle  button. 


Another  implementation  of  a  toggle  button  is  the  Maximize/Restore  (middle)  button  found  on  the 
top  right  comer  of  Microsoft  windows.  When  the  window  is  not  maximized,  the  Maximize 
button  is  displayed  to  denote  the  ability  to  perform  the  “Maximize”  action.  When  the  window  is 
maximized,  the  Restore  button  replaces  the  Maximize  button  thereby  indicating  the  ability  to 
return  the  window  to  its  previous  state. 


=1Q]xJ 


Figure  15:  Example  of  a  maximize/restore  toggle  button. 


13.9  Toggle  button  characteristics 

1.  The  toggle  buttons  may  be  modified  so  that  they  appear  as  push  buttons.  Flowever,  the 
resulting  behaviour  is  that  such  a  "push  button"  remains  highlighted  when  <Select>  is 
released  and  returns  to  its  previous  appearance  only  when  another  button  of  the  same  type 
is  selected.  This  scheme  shall  be  implemented  when  buttons  are  used  to  both  execute  an 
action  and  to  provide  an  indicator  of  the  action  selected.  The  column  headings  in  multi- 
column  list  boxes  shall  be  toggle  buttons  that  look  like  push  buttons. 

2.  Include  both  states  of  the  settings  on  the  menu  as  individual  menu  items  and 
interdependent  choices.  The  operator  may  then  view  both  options  at  once.  Use  toggles 
and  toggled  labels  only  if  there  is  insufficient  room  to  display  both  of  the  toggled  options. 

3.  Toggle  buttons  and  indicators  in  menus  shall  be  visible  when  in  the  off  state. 

4.  Settings  that  are  state  toggles  shall  be  worded  to  describe  a  state  (e.g.,  a  list  of  font 
names)  and  may  be  indicated  by  option  buttons  or  check  boxes  to  the  left  of  the  option. 
(TBM,  CSFAB) 

5.  Only  one  of  the  actions  for  a  toggle  menu  option  shall  appear  in  the  menu  at  any  time. 

Source 

CSFAB,  TBM,  MSWUE. 
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13.9.1  Toggle  button  labels 

1.  If  there  is  not  sufficient  room  to  display  both  of  the  toggled  options,  then  settings  that  are 
action  toggles  (e.g.,  turn  on/tum  off)  shall  be  worded  to  reflect  the  action  that  is 
implemented  when  the  option  is  selected  and  shall  change  to  reflect  the  opposite  action 
that  will  occur  if  the  toggle  is  selected  again. 

2.  When  a  state  toggle  is  selected,  the  indicator  shall  change  state  without  altering  the 
wording. 

3.  When  an  action  toggle  is  selected,  its  wording  shall  change  to  reflect  the  action  that  will 
be  implemented  when  the  action  is  selected  again  (e.g.,  if  a  menu  option  is  worded  Show 
Tool  Bar  it  will  be  changed  to  Hide  Tool  Bar  after  it  has  been  selected). 

4.  Wording  of  an  undo  option  shall  change  dynamically  to  reflect  the  action  to  be  undone. 
For  example,  if  the  most  recently  executed  action  is  “Cut”,  the  option  shall  be  worded 
“Undo  Cut”. 

5.  Wording  of  an  action  toggle  option  shall  reflect  the  action  implemented  when  the  option 
is  selected.  For  example,  if  a  menu  action  toggle  is  being  used  to  show  political 
boundaries  on  a  map,  the  menu  option  shall  be  worded  “Show  Political  Boundaries” 
rather  than  just  “Political  Boundaries”  to  indicate  that  political  boundaries  will  be 
displayed  when  the  option  is  selected. 

6.  Wording  of  an  action  toggle  option  is  semantically  congruent  with  natural  usage.  For 
example,  if  one  toggle  is  worded  “Move  Object  Up”  the  other  toggle  shall  be  “Move 
Object  Down”  rather  than  “Move  Object  Back”. 


Source 

CSFAB,  TBM,  MSWUE. 

Discussion 

G 1 .  Action  toggles  that  use  changed  wording  to  convey  the  action  that  will  happen  when  the 
toggle  is  selected  shoidd  not  be  displayed  in  the  pressed  state  because  users  find  it  unintuitive  to 
press  a  button  that  is  already  pressed. 


13.10  Checkboxes 

Check  boxes  allow  users  to  toggle  the  state  or  setting  for  option(s).  The  example  shown  below  is 
of  a  check  box  implementation  that  allows  the  user  to  adjust  the  various  Pagination  settings  for  a 
Microsoft  Word  document. 


W  Widow/Orphan  control  F  Keep  with  next 

U  Keep  lines  together  W  Page  break  before 

Figure  16:  Example  of  check  boxes. 
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13.10.1  Check  boxes  characteristics 


1 .  A  check  box  shall  be  used  to  set  options  in  an  application. 

2.  A  check  box  shall  be  a  non-exclusive  setting;  selecting  a  check  box  toggles  a  setting  or 
state. 

3.  Check  boxes  shall  not  be  used  to  initiate  actions  or  open  dialogs. 

4.  Check  boxes  shall  be  used  singly  or  in  related  groups. 

5.  Check  boxes  shall  be  displayed  in  vertical  groupings,  but  horizontal  grouping  is  permitted 
if  more  beneficial  due  to  space  requirements. 

6.  The  number  of  check  boxes  in  a  group  shall  be  limited  to  eight  or  less  and  shall  include  a 
title  that  describes  the  type  of  information  being  presented. 

7.  When  check  boxes  are  selected  but  not  executed,  the  application  shall  not  save  the 
selection  and  the  check  boxes  shall  return  to  their  original  state  when  the  window  is 
displayed. 


Source 

CSFAB,  TBM. 

13.10.2  Check  box  size 

1 .  Check  boxes  shall  be  the  same  size  throughout  the  application. 

2.  Check  boxes  shall  be  of  sufficient  size  to  be  suitable  targets  in  Maritime  operations. 

Source 
TBM,  UCA. 

Discussion 

G2.  The  active  area  for  a  check  box  can  be  visually  enhanced  by  displaying  the  entire  active 
area  of  the  button  to  the  operators.  Even  advanced  users  tend  to  use  the  small  target  of  the  check 
box  graphic  rather  than  the  entire  active  area.  The  standard  check  box  size  presents  too  small  a 
target  to  be  suitable  for  Maritime  operations. 

13.10.3  Check  box  interaction 

1 .  The  S  button  on  the  pointing  device  shall  be  used  to  select  a  check  box. 

2.  When  the  location  cursor  is  on  a  check  box,  <Space>  (and  <Select>  if  available)  shall 
select  a  check  box  from  the  keyboard. 

3.  When  a  check  box  is  selected,  it  shall  be  highlighted  and  any  other  button  in  that  check 
box  group  which  has  been  previously  selected  shall  stay  selected. 
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4.  If  a  check  box  is  in  a  window  with  a  default  action,  <Enter>  or  <Retum>  shall  execute 
the  action. 


Source 

TBM. 

13.11  Listboxes 

List  boxes  are  used  to  view  and  scroll  through  several  related  items.  The  illustrated  list  box 
provides  the  user  with  a  list  of  several  toolbar  types. 


Categories: 

File 

Edit 

View 

Insert 

Format 

Tools 

▲ 

2d 

Table 

Web 

Window  and  Help 
Drawing 

Figure  17:  Example  of  a  list  box  (taken  from  Microsoft  word). 

13.11.1  List  box  characteristics 

1.  The  items  in  a  list  shall  be  displayed  vertically,  with  one  item  per  line.  In  general,  a  list 
box  shall  be  large  enough  to  display  six  to  eight  items  at  a  time  or  all  of  the  items  if  there 
are  fewer  than  six. 

2.  The  title  of  the  list  shall  describe  its  purpose  or  contents  and  appear  above  the  box. 

3.  A  vertical  scroll  bar  shall  appear  to  the  right  of  the  list  when  items  exceed  space 
available. 

4.  A  list  shall  scroll  only  in  response  to  user  actions  such  as  using  a  scroll  bar  or  conducting 
a  speed  or  incremental  search.  A  list  does  not  scroll  automatically  (e.g.,  whenever  the 
contents  of  the  list  are  updated  through  an  automatic  process  or  a  user  generated  process 
such  as  editing  a  list  item). 

5.  A  list  shall  be  wide  enough  to  read  the  items  without  having  to  scroll  horizontally.  If 
items  differ  significantly  in  length,  then  the  list  box  shall  be  wide  enough  to  display  the 
items  of  average  length  and  include  horizontal  scroll  bars  to  allow  longer  items  to  be 
read. 

6.  List  items  shall  appear  in  sequential  order  based  on  the  nature  of  items  and  sequence 
expected  (e.g.,  chronological,  alphabetical,  sequential,  functional,  and  by  importance). 

7.  A  series  of  list  boxes  may  be  arranged  horizontally  in  a  row  to  form  a  multi-column  list 
box  or  matrix. 
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8.  In  multi-column  list  boxes,  the  list  box  titles  serve  as  the  column  headings  in  the  matrix, 
and  the  items  in  each  list  form  the  records  that  appear  in  the  rows.  Users  shall  be  able  to 
sort  the  records  by  selecting  the  column  heading.  With  this  approach,  the  headings  of 
columns  that  can  be  sorted  appear  as  push  buttons,  and  when  users  select  a  heading  the 
records  in  the  matrix  are  sorted  in  ascending  order  (e.g.,  numerical  or  alphabetical)  based 
on  the  items  in  the  column. 

9.  Items  added  to  a  list  shall  appear  in  their  correct  position  in  the  list,  not  at  the  end  of  the 
list. 

10.  The  list  shall  not  automatically  scroll  to  the  new  item  except  during  initial  entry.  Only 
user  initiated  scroll  is  permitted. 

11.  Vertical  extension.  Where  lists  extend  over  more  than  one  display  page,  the  last  line  of 
one  page  shall  be  the  first  line  on  the  succeeding  page. 

12.  Marking  multi-line  items  in  a  list.  Where  a  single  item  in  a  list  continues  for  more  than 
one  line,  such  items  shall  be  marked  in  some  way  (e.g.,  blank  line,  indentation)  so  that  the 
continuation  of  the  item  is  obvious. 


Source 

CSFAB,  TBM,  DISA,  MS1472F,  MSWUE. 

Discussion 

G4.  Auto-scrolling  is  acceptable  when  the  user  is  adding  new  items  to  a  list.  When  new  items 

are  added,  they  shall  appear  in  the  default  sort  order  of  the  list  and  the  list  shall  automatically 

scroll  to  place  the  newly  added  item  at  the  top  of  the  list.) 

G8.  For  a  description  of  column  heading  controls,  see  MSWUE  (Chapter  8). 

13.11.2  List  box  navigation  and  selection 

1.  Lists  in  which  users  can  select  an  item(s)  upon  which  to  perform  an  action  shall  use  a 
pop-up  menu  to  display  these  options.  Push  buttons  shall  be  used  to  provide  redundancy 
for  options  displayed  in  the  pop-up  menu.  Push  buttons  shall  be  used  when  there  is  a 
standard  push  button  assignment 

2.  In  an  initial  list  box  display,  the  current  selection  or  a  default  selection  shall  be 
highlighted  and  the  list  scrolled  to  place  this  item  at  the  top  of  the  list  box. 

3.  Users  shall  search  a  list  by  moving  the  scroll  bar  slider  until  the  item  appears.  The  arrow 
keys  shall  also  scroll  the  items  in  a  list. 

4.  Applications  shall  provide  a  speed  search  capability  in  all  list  boxes.  Speed  search  allows 
the  user  to  type  the  first  letter  of  the  selection  to  quickly  move  to  those  options  beginning 
with  that  letter. 

5.  In  list  boxes  where  the  number  of  items  is  expected  to  be  large  (e.g.,  in  excess  of  20 
items),  speed  search  shall  be  implemented.  In  speed  search  the  user  must  place  the 
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location  cursor  on  the  list.  When  the  user  types  the  first  letter  of  the  item,  the  list  shall 
scroll  to  the  first  instance  that  begins  with  the  letter  the  user  types. 

6.  In  list  boxes  where  the  number  of  items  is  expected  to  exceed  50  items,  incremental 
search  shall  be  provided.  When  the  user  types  the  first  few  letters  in  the  text  field  and 
presses  <Retum>,  the  list  shall  scroll  to  the  first  match. 

7.  Speed  search  and  incremental  search  shall  not  be  case-sensitive.  If  case-sensitivity  is  a 
user  requirement,  then  this  information  is  provided  to  users. 

8.  The  S  button  on  the  pointing  device  shall  be  used  to  select  item(s)  in  a  list  box. 

9.  List  items  shall  be  selectable  by  both  the  pointer  and  the  keyboard.  Lists  can  allow  for 
either  mutually  exclusive  selection  or  multiple  selections. 

10.  The  <Space>  key  (<Select>  if  available)  shall  selects  item(s)  in  a  list  from  the  keyboard. 

11.  If  a  window  has  a  default  action,  double  clicking  on  an  item  chooses  the  item  and 
executes  the  action.  However,  double  clicking  shall  not  be  the  only  means  to  execute  the 
action. 


Source 

CSFAB,  TBM. 

13.12  Scroll  bars 

Scroll  bars  allow  users  to  view  textual  or  graphic  information  when  that  information  exceeds  the 
available  display  area  in  the  window.  Below  is  a  horizontal  scroll  bar  with  the  various 
components  labelled.  If  scroll  bars  are  required,  vertical  scroll  bars  are  preferred. 


m 

- 

=nr- 

±J 

o  oi  tnn 

Scroll  arrow 

i  i  i  1 1  i’t  In*  If~-  — 

Scroll  box  | 

Figure  18:  Example  of  a  scroll  bar. 


13.12.1  Scroll  bar  characteristics 

1.  If  scroll  bars  are  needed,  they  shall  be  located  to  the  right  or  at  the  bottom  of  the  area 
being  scrolled. 

2.  Scroll  bars  shall  be  used  to  view  textual  or  graphic  information  when  it  exceeds  the 
available  display  area  in  the  window.  All  text  shall  wrap  so  that  it  can  be  read 
continuously  without  horizontal  scrolling.  Horizontal  scrolling  shall  be  avoided.  If  a 
scroll  bar  is  not  needed  it  shall  be  removed  from  the  display. 

3.  Items  continued  on  a  following  page  (scrolled)  shall  be  numbered  relative  to  the  last  item 
on  the  previous  page. 
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4.  Users  shall  be  able  to  scroll  to  the  top  or  the  bottom  of  the  scroll  region  but  not  beyond. 

5.  Relative  slider  position  shall  indicate  relative  position  of  information  currently  displayed 
in  the  window. 

6.  Scroll  bar  tips  shall  be  provided.  The  scroll  bar  tips  shall  be  implemented  in  accordance 
with  Microsoft  Windows  conventions. 


Source 

CSFAB,  TBM,  D1SA,  MS1472F,  UCA. 

Discussion 

G7.  Scroll  bar  tips  are  similar  to  Tool  Tips  and  are  displayed  when  the  user  presses  the  scroll 

bar  thumb  (the  button  in  the  centre  of  the  scroll  bar  trough.)  Scroll  bar  tips  are  described  in 

Developing  User  Interfaces  for  Microsoft  Windows  [46]. 

13.12.2  Scroll  bar  navigation  and  selection 

1 .  Pressing  the  S  button  on  a  stepper  arrow  shall  move  one  unit  in  the  arrow  direction.  A 
unit  is  defined  as  a  column  for  a  horizontal  scroll  bar  and  a  line  for  a  vertical  scroll  bar. 

2.  Pressing  the  S  button  on  a  trough  shall  move  one  page  (less  one  unit)  in  the  direction 
indicated.  A  page  is  defined  as  one  window  length  for  a  vertical  scroll  bar  and  one 
window  width  for  a  horizontal  scroll  bar. 

3.  Dragging  the  slider  with  the  S  button  shall  move  the  slider  in  the  pointer  direction. 

4.  The  virtual  <Cancel>  key  shall  return  the  slider  to  its  position  before  the  sliding  operation 
began. 

5.  Dragging  past  the  top/bottom  of  the  scrollable  area  shall  make  the  window  scroll  in  the 
pointer  direction. 

6.  The  speed  of  autoscrolling  shall  be  the  same  as  when  the  users  press  on  a  stepper  arrow. 

7.  Scrolling  shall  stop  when  users  move  the  pointer  back  into  the  control  or  when  users 
release  the  Select  button  on  the  pointer  device. 

8.  Arrow  keys  shall  move  the  slider  one  unit  (e.g.,  one  line  or  column)  in  the  arrow 
direction. 

9.  Pressing  <Ctrl>  with  the  arrow  keys  shall  move  the  slider  one  large  increment  in  the 
arrow  direction. 

10.  <PageUp>,  <PageDown>,  <PageRight>  (or  <Ctrl>  +  <PageUp>),  and  <PageLeft>  (or 
<Ctrl>  +  <PageDown>  shall  page  the  screen  in  the  specified  direction. 

11.  <Ctrl>  +  <Begin>  and  <Ctrl>  +  <End>  shall  scroll  to  the  beginning/end  of  the  scrollable 
region. 
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Source 


TBM,  DISA. 

13.13  Scales 

A  scale  is  used  to  set  or  display  a  value  in  a  continuous  range.  To  adjust  the  values  along  a  scale, 
a  slider  can  be  implemented  whereby  the  user  can  drag  the  pointer  across  specified  positions 
along  the  line.  The  slider  illustrated  below  provides  the  capability  to  adjust  the  speed  with  which 
the  pointer  moves  within  the  Microsoft  operating  system. 


Figure  19:  Example  of  a  scale. 

13.13.1  Scale  characteristics 

1 .  A  scale  shall  be  used  to  set  or  display  a  value  in  a  continuous  range. 

2.  A  scale  may  contain  tick  marks  and  is  labelled  with  minimum/maximum  values  for  the 
scale. 

Source 

CSFAB,  TBM,  DISA. 
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Discussion 


G2.  A  scale  can  only  be  used  with  numeric  values.  This  limits  its  use.  The  scale  shall  be  used 
where  users  are  primarily  operating  with  a  pointing  device  to  help  reduce  transitions  between  the 
keyboard  and  pointing  device.  A  scale  may  also  be  used  in  an  output  only  mode.  This  is 
sometimes  called  a  gauge.  The  value  of  using  a  scale  in  this  mode  is  that  by  displaying  minimum 
and  maximum  values,  users  can  quickly  see  the  present  setting  in  a  continuum  and  have  an  idea 
how  far  the  setting  is  from  the  extreme  values. 

13.13.2  Scale  navigation  and  selection 

1.  Users  shall  display  a  value  by  adjusting  a  slider  (bar  or  arrow)  to  a  specified  position 
along  a  line.  A  scale  shall  contain  a  slider  marking  the  currently  chosen  scale  value,  and  a 
label  above  or  next  to  the  slider  showing  the  current  value  of  the  scale. 

2.  Pressing  the  S  button  on  the  scale  bar  shall  move  one  increment  at  a  time  in  the  direction 
indicated. 

3.  Dragging  the  slider  with  the  S  button  shall  move  the  slider  in  the  pointer  direction. 

4.  <Cancel>  shall  return  the  slider  to  its  position  before  the  sliding  operation  began. 

5.  Arrow  keys  shall  move  the  slider  one  unit  in  the  arrow  direction. 

6.  <Ctrl>  with  the  arrow  keys  shall  move  the  slider  one  large  increment  in  the  arrow 
direction. 

7.  <Ctrl>  +  <Begin>  and  <Ctrl>  +  <End>  shall  move  the  slider  to  minimum/maximum  scale 
values. 


Source 

CSFAB,  TBM. 


13.14  Other  controls 


13.14.1  Other  control  characteristics 

1.  If  a  non-standard  control  is  used,  it  shall  have  as  much  of  the  standard  look  and  feel  as 
possible. 

2.  Non-standard  controls  shall  maintain  a  three-dimensional  appearance  since  they  are 
controls  and  can  be  manipulated  by  the  user. 


Source 

TBM,  UCA. 
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13.14.2  Modified  push  button  behaviour 

1 .  When  push  buttons  are  used  to  execute  an  action  and  provide  an  indicator  of  the  action 
selected,  the  push  button  may  be  modified  so  that  it  stays  highlighted. 

2.  A  push  button  palette  may  be  used  to  provide  access  to  a  set  of  frequently  performed 
actions. 

3.  Push  buttons  in  a  palette  shall  represent  a  set  of  mutually  exclusive  options. 

Source 

TBM. 


13.14.3  Drop-down  combination  boxes 


Similar  to  a  list  box,  a  drop-down  combination  box  uses  the  standard  text  field  and  list  widgets. 
A  drop-down  combination  box  allows  the  selected  item  to  be  set  off  from  the  list  and  allows  for 
subsequent  letter  speed  search  instead  of  only  first  letter  speed  search.  As  shown  below,  these 
boxes  allow  the  user  to  create  a  new  file  name  or  select  from  a  pre-defined  list  of  file  names  as 
well  as  to  select  a  format  for  saving  the  file. 


File  name: 
Save  as  type: 


3 

Rich  Text  Format  ▼ 

All  Files  -»■ 

All  Word  Documents 
Word  Documents 
Web  Pages 

Document  Templates _ 


Rich  Text  Format 


Figure  20:  Example  of  a  drop-down  combination  box. 

1.  Drop-down  combination  boxes  are  used  to  fill  a  text  field  when  the  number  of  valid 
entries  in  the  field  is  limited  or  very  large. 

2.  Combination  boxes  combine  the  standard  text  field  and  list  widgets.  This  allows  the 
selected  item  to  be  set  off  from  the  list  and  allows  for  subsequent  letter  speed  search 
instead  of  only  first  letter  speed  search. 

3.  Combination  boxes  are  generally  used  for  long  lists  but  could  be  substituted  for  any  list 
with  mutually  exclusive  selections.  They  may  be  implemented  in  standard  or  drop-down 
mode. 

4.  See  MSWUE  for  the  appearance  and  behaviour  of  combination  boxes. 

5.  The  availability  of  a  drop-down  combination  box  shall  be  indicated  by  an  arrow  push 
button  to  the  right  of  the  text  field. 

6.  Items  in  a  drop-down  combination  box  shall  allow  users  to  select  from  valid  entries  or 
cancel  the  selection. 
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7.  Drop-down  combination  boxes  shall  be  wide  enough  to  read  items  in  the  list  and  include 
vertical  scroll  bars  if  necessary. 


Source 

CSFAB,  TBM,  UCA. 

13.14.4  Spin  boxes 

Spin  boxes  consist  of  a  text  field  with  arrows  attached  to  the  right  side  of  the  text  field.  The 
arrows  are  organized  with  an  upward  pointing  arrow  above  a  downward  pointing  arrow.  Pressing 
the  arrow  buttons  allows  the  user  to  increment  (or  decrement)  the  value  in  the  text  field.  The  spin 
boxes  illustrated  below  provides  the  user  with  the  ability  to  change  the  spacing  before  and  after  a 
paragraph  in  a  Microsoft  Word  document. 


Figure  21:  Example  of  a  spin  box. 

1.  Spin  boxes  are  specialized  text  fields  and  shall  accept  only  a  limited  set  of  discrete, 
ordered  data  entry  values.  A  spin  box  shall  consist  of  a  text  field  with  an  upward  pointing 
arrow  above  a  downward  pointing  arrow  attached  to  the  right  side  of  the  text  field. 

2.  If  space  is  at  a  premium  and  if  the  usability  of  the  CCS  is  not  negatively  impacted,  a  spin 
box  may  be  used  instead  of  a  scale.  Spin  boxes  are  also  slower  to  use  than  scales  when 
using  a  pointing  device,  as  the  operator  must  step  through  all  values  to  reach  a  desired 
value. 

3.  The  designer  shall  define  the  increment  values  for  the  spin  box.  Pressing  the  up  or  down 
arrow  shall  change  the  existing  counter  value  to  the  next  higher  or  lower  increment. 

4.  A  spin  box  shall  allow  a  user  to  type  into  the  text  field,  click  the  up  arrow  to  increase  the 
value  in  the  text  field,  or  click  the  down  arrow  key  to  decrease  the  value  in  the  text  field. 

5.  If  a  user  presses  the  up  arrow  or  the  down  arrow  and  holds  the  selection  pointer  down,  the 
text  field  shall  step  through  its  values  continuously  in  the  direction  of  the  arrow  button 
until  the  selection  pointer  button  is  released.  When  either  end  of  the  scale  is  reached,  the 
value  shall  wrap  around  to  the  other  end  and  continue  stepping  through  the  list  until  the 
selection  pointer  button  is  released. 

6.  If  spin  boxes  are  used  to  display  values  that  consist  of  several  subcomponents,  the  text 
component  is  divided  into  text  fields  separated  by  suitable  separators  and  the  arrows 
affect  the  selected  text  field. 


Figure  22:  Example  of  a  Component  Spin  box.  It  has  several  subcomponents  with  the  text  fields 
separated  by  colons  whereby  the  arrows  affect  the  highlighted  text  field  (i.e.,  minutes). 
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7.  A  value  typed  into  a  spin  box  shall  be  validated  for  correct  syntax  and  format  as  the  user 
leaves  the  text  field  widget. 

8.  Spin  boxes  shall  not  be  used  if  there  is  a  more  direct  way  to  select  the  values.  (An 
example  of  a  direct  way  to  select  values  is  selecting  dates  via  a  calendar  widget.) 


Source 

CSFAB,  TBM,  UCA. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  ease  of  use,  design  consistency,  and  visibility  of  all  controls  used  in  the 
OML 

Operator  performance: 

•  Objective  assessment  of  use  and  usefulness  of  controls. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  perceptions  of  usability,  utility,  and 
consistency  of  controls  in  the  OM1  and  ESS. 
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14  Menus 


Menus  provide  a  means  for  the  operator  to  access  functions  in  a  hierarchical  fashion  that  requires 
decreased  display  space  and  decreased  cognitive  requirements.  While  this  means  of  accessing 
functions  requires  less  memorization,  it  is  generally  slower  for  experienced  operators  who  have 
already  learned  common  function  keys.  The  deeper  a  function  is  located  in  a  menu  hierarchy  the 
longer  it  will  take  to  access  that  function  and  the  more  difficult  it  will  be  to  remember  how  to 
navigate  to  that  function. 
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Figure  23:  Illustration  of  several  generic  menu  characteristics  in  accordance  with  the 

requirements  defined  in  this  section. 


14.1  Menu  characteristics 

1.  Menu  titles,  controls,  separators,  access  keys,  layouts  and  other  details  are  presented  in 
MSWUE  (Chapter  8).  The  Microsoft  windows  visual  layout  shall  be  followed. 

2.  The  number  of  hierarchical  levels  used  to  control  a  process  or  sequence  shall  be  minimal. 

3.  Those  functions  that  are  used  frequently  or  are  time  critical  shall  be  accessible  via  a 
single  action.  This  group  of  functions  may  change  depending  on  the  task  being  performed 
and  shall  be  reflected  in  the  menus  required  during  these  tasks.  If  the  function  needs 
frequent  access,  then  a  single  layer  menu  is  required. 

4.  Display  and  input  formats  shall  be  similar  within  hierarchical  levels  of  menus.  The 
system  shall  indicate  the  current  positions  within  the  sequence  at  all  times. 

5.  Menus  shall  be  used  for  tasks  that  involve  little  or  no  entry  of  arbitrary  data  and  where 
users  may  have  relatively  little  training.  Menus  shall  also  be  used  when  a  command  set  is 
so  large  that  users  are  not  likely  to  be  able  to  commit  all  of  the  commands  to  memory. 
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6.  Menu  groups  are  related  menu  options  within  the  same  menu  window.  Grouping  allows 
operators  to  more  quickly  scan  options  by  skipping  entire  groups  of  options  until  the 
desired  group  is  located.  Each  menu  group  shall  be  separated  from  other  groups  and 
contain  a  limited  number  of  options. 

7.  Options  shall  not  be  added  to  or  deleted  from  a  menu  to  indicate  their  availability  within 
a  particular  part  of  an  application. 

8.  A  menu  shall  not  consist  of  a  long  list  of  multi-page  options,  but  shall  be  logically 
segmented  to  allow  several  sequential  selections  among  a  few  alternatives. 

9.  On  any  type  of  menu,  a  menu  option  that  displays  a  window  shall  be  followed  by  an 
ellipsis  (...). 

10.  A  routing  option  that  displays  a  cascading  submenu  shall  be  followed  by  a  right-pointing 
arrow. 


Source 

CSFAB,  TBM,  D1SA,  MS1472F,  MSWUE,  UCA. 

14.2  Menus  organization  and  grouping 

1 .  The  number  of  levels  required  to  access  a  specific  function  is  referred  to  as  the  depth  of 
the  menu.  To  increase  function  access  speed,  a  broad  and  shallow  menu  tree  shall  be 
used.  Broad  meaning  that  each  level  in  the  menu  tree  contains  many  functions  and 
shallow  meaning  that  the  menu  tree  shall  only  contain  two  functions. 

2.  The  limit  on  the  number  of  levels  is  determined  by  the  number  of  actions  required  to 
activate  an  option.  No  matter  where  the  operator  is  in  the  menu  hierarchy,  the  operator 
shall  be  able  to  access  any  function  with  only  three  actions  (e.g.,  one  press  to  get  back  to 
the  main  level,  one  press  to  select  the  proper  group  of  functions,  and  one  press  to  select 
the  desired  function). 

3.  Single  layer  menus  shall  be  used  for  reserved  commands  that  never  change  and  must 
always  be  available  to  the  operator.  Fixed  Action  Buttons  (FABs)  are  a  common  type  of 
single  layer  menu  and  can  be  virtual  or  real  buttons  that  provide  the  operator  with 
immediate  access  to  a  set  group  of  commands. 

4.  When  menu  traversal  can  be  accomplished  by  clearly  defined  hierarchical  paths,  the  user 
shall  be  given  some  indication  of  the  displayed  menu’s  current  position  in  the  overall  or 
relevant  structure  (e.g.,  an  optional  display  of  path  information  or  cascading  menus). 

5.  The  user  shall  be  able  to  return  to  the  next  higher  level  of  hierarchical  menus  by  using 
single  key  action  until  the  initial,  top-level  menu  or  display  is  reached. 

6.  A  function  shall  be  provided  to  directly  recall  the  initial,  top-level  menu  or  display 
without  stepping  through  the  menu  or  display  hierarchy. 
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7.  Dialog  boxes  shall  be  used  as  an  aid  for  composing  complex  control  entries.  For  example, 
a  displayed  form  might  help  a  user  invoke  the  various  format  controls  that  are  available  to 
complete  a  print  request. 

8.  Structured  menus  shall  be  used  to  provide  access  to  functions  when  space  and  cognitive 
memory  resources  are  limited.  By  segmenting  functions  into  common  menus  and/or 
groups,  only  those  functions  that  are  required  for  a  specific  task  are  available  thus 
reducing  clutter. 

9.  The  display  of  information  accessed  by  tabs  (e.g.,  menus  based  on  an  index  card  tab 
concept)  shall  not  include  more  than  one  layer  of  tabs. 

10.  The  display  of  information  accessed  by  tabs  shall  clearly  indicate  which  tab  is  selected. 
The  selected  tab  shall  appear  to  be  in  front  of  the  remaining  tabs. 

1 1 .  When  a  tab  is  selected  the  outline  of  the  selected  page  shall  appear  in  front  of  the 
remaining  pages. 


Source 

CSFAB,  MS1472F,  UCA. 

14.3  Menu  mnemonics 

1 .  Mnemonics  shall  be  available  for  every  title  in  a  menu  bar  and  every  option  in  all  menus. 

2.  The  mnemonics  assigned  to  titles  in  a  menu  bar,  and  to  options  within  a  menu,  shall  be 
unique. 

3.  A  menu  title  or  option  shall  have  the  same  mnemonic  whenever  it  appears  in  an 
application. 

4.  The  mnemonics  listed  in  MSWUE  shall  be  used  in  menu  titles  and  options. 

5.  The  same  mnemonic  shall  not  be  used  for  options  performing  opposite  or  contradictory 
actions. 

6.  Letters  shall  be  used  for  mnemonic  codes  if  they  relate  to  the  spelling  of  the  command. 
Flowever,  letters  that  do  not  relate  to  a  command  shall  not  be  used  because  they  are  worse 
than  numbers. 

7.  Numbers  are  useful  for  sequential  lists  and  for  easy  location  by  non-typists.  If  numbers 
are  used  as  mnemonics,  one  (1)  shall  be  used  for  the  first  option,  do  not  use  zero  (0). 

8.  Similar  key(s)  shall  be  used  in  the  mnemonic  and  keyboard  accelerator  for  a  menu  option. 

9.  The  character  assigned  as  the  mnemonic  for  a  menu  title  or  menu  option  shall  be 
underlined. 

10.  Whenever  possible,  the  mnemonic  shall  be  the  first  letter  of  a  menu  title  or  option. 
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1 1 .  If  the  mnemonic  is  not  the  first  letter,  the  mnemonic  shall  be  another  character  in  a  menu 
title  (or  option)  rather  than  more  arbitrary  numeric  codes. 

12.  If  the  mnemonic  character  does  not  appear  in  a  menu  title  or  option,  it  shall  be  in 
parentheses  after  the  label. 

13.  Mnemonics  shall  not  be  case-sensitive. 

14.  If  the  location  cursor  is  in  the  menu  bar,  typing  a  mnemonic  shall  display  the  associated 
menu. 

15.  When  a  menu  is  displayed,  typing  a  mnemonic  shall  select  the  associated  option. 

Source 

CSFAB,  TBM,  D1SA,  MS1472F,  MSWUE. 

14.4  Menu  wording,  organization,  and  availability 

14.4.1  Menu  wording 

1.  Each  option  shall  be  phrased  to  reflect  the  action  that  is  executed  or  the  object  that  is 
modified  by  the  option  (i.e.,  phrased  as  a  command  to  the  computer  rather  than  as  a 
question  to  the  user). 

2.  Options  shall  be  worded  in  the  vocabulary  of  users  rather  than  that  of  application 
developers  or  other  populations. 

3.  The  vocabulary  listed  in  MSWUE  shall  be  used  whenever  actions  are  included  in  an 
option  (e.g.,  Save,  Cut,  Delete,  and  Find).  Whenever  an  action  is  available  in  OSF/Motif 
that  is  not  identified  in  Windows  then  the  Motif  vocabulary  shall  be  used. 

4.  The  key  word  of  the  command  shall  be  the  first  word  in  the  option. 

5.  Each  option  shall  be  tersely  worded  (preferably  limited  to  a  single  word)  and  follow  book 
title  capitalization  rules.  (CSFAB,  MSWUE) 

6.  Acronyms  in  menu  option  titles  shall  be  capitalized. 

Source 

CSFAB,  TBM,  D1SA,  MSWUE,  UCA. 

14.4.2  Menu  organization 

1.  Each  menu  option  shall  be  left  justified  and  appear  on  a  single  line;  long  menu  options 
shall  be  accommodated  by  making  the  menu  wider  rather  than  making  the  item  take  two 
(or  more)  lines. 
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2.  Menus  shall  be  presented  in  a  consistent  format  throughout  the  system  and  shall  be 
readily  available  at  all  times. 

3.  When  selections  are  indicated  by  coded  entry,  the  code  associated  with  each  option  shall 
be  included  on  the  display  in  a  consistent  manner. 

4.  If  several  levels  of  hierarchical  menus  are  provided,  a  direct  function  call  capability  shall 
be  provided  such  that  the  experienced  user  does  not  have  to  step  through  multiple  menu 
levels. 

5.  The  menu  shall  be  wide  enough  to  accommodate  the  longest  option  and  accelerator. 

Source 

CSFAB,  TBM,  MS1472F,  MSWUE. 

Discussion 

G5.  An  accelerator  is  a  keyboard  key  or  key  combination  that  invokes  a  particular  command. 
Some  references  distinguish  between  accelerators  (key  combinations,  for  example  <Ctrl>  +  <Z> 
for  Undo)  and  short  cut  keys  (function  keys).  Other  references  refer  to  both  the  key  combinations 
and  functions  keys  as  accelerators.  In  this  document  the  term  accelerator  refers  to  both  function 
keys  and  key  combinations. 

14.4.3  Menu  option  grouping 

1.  Menu  options  shall  be  organized  in  logical  or  functional  groupings.  Options  that  are 
related  shall  be  divided  by  a  separator  line.  The  separator  line  is  a  single  line  that  spans 
the  width  of  the  menu.  Separation  into  groups  will  allow  operators  to  more  quickly  find  a 
desired  option. 

2.  The  maximum  number  of  menu  titles  in  the  main  menu  bar  shall  be  nine. 

3.  The  number  of  options  in  a  pull-down  menu  shall  be  limited  to  fourteen. 

4.  As  a  guideline,  a  menu  shall  contain  no  less  than  three  options  or  more  than  ten  options. 

5.  The  number  of  options  in  each  menu  group  shall  be  limited  to  five. 

6.  Menu  items  themselves  shall  not  be  used  as  group  separators  in  menus. 

7.  If  the  menu  options  are  not  ordered  in  logical  groups,  options  shall  be  ordered  by 
frequency  of  usage,  with  the  most  frequent  at  the  top. 

8.  If  the  menu  options  are  not  ordered  in  logical  groups  or  by  frequency,  options  shall  be 
ordered  in  alphabetical  or  numerical  order. 

9.  Less  frequently  executed  options  and  destructive  options  shall  be  at  the  bottom  of  the 
menu. 
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10.  If  similar  options  are  in  different  menus,  the  options  shall  be  ordered  in  a  consistent 
manner. 

1 1 .  Menus  with  more  than  four  to  five  options  shall  be  divided  into  subgroups  of  options,  as 
appropriate.  Groups  of  menu  options  are  separated  by  a  separator  line. 


Source 

CSFAB,  TBM,  D1SA,  MS1472F,  MSWUE. 

14.4.4  Menu  Availability 

1.  If  an  option  or  set  of  options  is  never  available  to  a  user,  the  option(s)  shall  not  be 
presented  in  a  menu. 

2.  If  an  option  is  only  temporarily  unavailable,  it  shall  be  displayed  in  the  menu  but  dimmed 
to  indicate  that  it  cannot  be  selected.  The  dimmed  function  remains  visible  to  indicate  or 
confirm  that  this  option  does  exist  but  is  not  available  due  to  the  status  of  the  system. 


Source 

CSFAB,  TBM,  D1SA,  MS1472F,  MSWUE. 

14.5  Menu  navigation  and  selection 

14.5.1  Pointer  navigation  and  selection 

1 .  When  a  menu  is  displayed,  the  location  cursor  shall  appear  on  the  first  available  option  in 
the  menu. 

2.  When  the  S  button  is  clicked  on  the  menu  title  the  menu  shall  remain  displayed. 

3.  Posted  methods  shall  be  used  to  display  a  menu  and  select  an  option. 

4.  When  the  S  button  is  clicked  on  the  option,  the  location  cursor  shall  move  to  the  option 
and  the  option  shall  be  selected.  The  menu  shall  then  be  removed. 

5.  To  dismiss  the  menu  without  selecting  an  option,  the  pointer  shall  be  moved  off  the  menu 
and  the  S  button  clicked. 


Source 

TBM,  MSWUE. 

Discussion 

G3.  TBM  include  spring-loaded  methods. 
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Keyboard  accelerator  navigation  and  selection 


1 .  Accelerators  shall  be  available  for  menu  options  that  are  frequently  executed. 

2.  Accelerators  consistent  with  the  Microsoft  Windows  styles  shall  be  used  for  the  actions 
listed. 

3.  Accelerators  shall  be  right  justified,  on  the  same  line,  and  separate  from  the  option  label. 

4.  Users  shall  be  able  to  execute  keyboard  accelerators  available  in  the  window  with  input 
focus. 

5.  Keyboard  accelerators  containing  an  alphabetic  character  shall  not  be  case-sensitive. 

6.  The  same  key  combinations  shall  be  used  for  accelerators  throughout  the 
application/system. 

7.  Key  combinations  for  accelerators  shall  not  conflict  with  mnemonics/text  entry 
keystrokes. 

8.  No  combination  of  adjacent  keys  shall  alone  be  used  as  an  accelerator.  This  reduces  the 
chance  of  accidentally  performing  a  function  while  typing. 

9.  Accelerators  shall  not  be  a  combination  of  <Alt>  and  letter  keys  (which  might  conflict 
with  mnemonics)  or  a  combination  of  <Shifit>  and  letter  keys  (which  might  conflict  with 
keystrokes  used  in  text  entry). 

10.  Fixed  function  key  interactive  control  may  be  used  for  tasks  that  require  only  a  limited 
number  of  control  inputs  or  in  conjunction  with  other  dialogue  types 


Source 

CSFAB,  TBM,  D1SA,  MS1472F,  UCA. 

14.6  Menu  title 

1 .  The  title  of  a  pull-down  menu  shall  be  displayed  in  a  menu  bar  at  the  top  of  a  window.  If 
possible,  a  menu  title  shall  be  limited  to  one  word. 

2.  A  menu  title  shall  describe  the  category  or  type  of  options  and  shall  be  different  from 
other  menu  titles  that  appear  in  the  same  menu  bar. 

3.  The  first  letter  of  each  word  in  the  menu  title  shall  be  capitalized,  in  accordance  with 
book  title  conventions. 

4.  If  a  menu  title  contains  an  acronym,  the  acronym  shall  be  capitalized. 

5.  A  menu  title  shall  not  contain  an  ellipsis  or  right-pointing  arrow. 

6.  The  Flelp  menu  title  shall  be  right-most  item  on  the  menu  bar. 
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7.  Menu  titles  in  a  menu  bar  shall  have  an  equal  amount  of  space  between  each  title. 

Source 

CSFAB,  TBM,  D1SA,  MS1472F,  MSWUE. 


14.7  Menu  types 

14.7.1  Pop-up  menus 


Pop-up  menus  provided  quick  access  to  actions  that  can  be  performed  on  the  selected  object.  The 
Pop-up  menu  illustrated  below  is  displayed  when  a  user  right-clicks  while  editing  text  in  a 
Microsoft  Word  document. 
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Figure  24:  Example  of  a  pop-up  menu. 


14.7.1.1  Pop-up  menu  characteristics 

1 .  Means  for  accessing  pop-up  menus  shall  be  one  of  the  following: 

■  Button  Press.  A  pop-up  display  mode  can  be  implemented  through  the  use  of  the 
right-hand  button  on  the  input  device. 

■  Time.  In  the  time  mode,  the  pop-up  menu  is  only  displayed  if  the  pointer  remains 
over  an  object  for  a  given  period  or  if  an  input  is  held  for  a  given  time  (as  with 
Tool  Tips). 

■  Pre-selection.  In  the  pre-selection  mode,  the  pop-up  menu  can  be  displayed  by 
simply  moving  the  cursor  over  an  object. 

2.  Pop-up  menus  shall  be  consistent  with  Microsoft  Windows  styles. 

3.  Pop-up  menus  shall  not  include  cascading  submenus. 

4.  The  options  in  a  pop-up  menu  shall  include  mnemonics  but  not  keyboard  accelerators. 

5.  The  options  in  a  pop-up  menu  shall  be  dimmed  when  unavailable. 
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6.  When  a  pointing  device  is  used,  the  pop-up  menu  contents  shall  relate  to  the  element  with 
the  pointer. 

7.  When  a  keyboard  is  used,  the  pop-up  menu  contents  relate  to  the  element  with  the 
location  cursor. 

8.  A  pop-up  menu  shall  appear  near  the  element  with  which  it  is  associated. 

9.  If  the  pop-up  menu  is  not  related  to  a  specific  object  then  it  shall  be  displayed  at  the 
pointer  location. 

10.  If  related  to  an  object,  the  menu  options  shall  be  specific  to  functions  performed  on  that 
object. 

1 1 .  A  window  containing  a  pop-up  menu  shall  provide  an  indication  that  the  menu  is 
available. 

12.  A  pop-up  menu  shall  provide  redundant  access  to  actions  and  shall  not  access  new 
actions.  This  means  that  options  in  a  pop-up  menu  must  also  be  accessible  via  a  main 
pull-down  menu  or  push  buttons. 

13.  A  pop-up  menu  shall  not  include  check  boxes  to  turn  settings  on  and  off. 

14.  A  pop-up  button-press  menu  shall  be  hidden  from  view  and  be  displayed  only  when 
selected  by  the  operator. 
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Source 


CSFAB,  TBM,  DISA,  MSWUE,  UCA. 

14.7.1.2  Pop-up  menus 

1 .  Posted  methods  shall  be  used  to  display  a  button-press  pop-up  menu. 

2.  Spring-loaded  methods  shall  be  used  to  display  time  or  pre-selection  pop-up  menus. 

3.  The  right-most  button  on  a  two-button  pointing  device  shall  display  pop-up  menus. 

4.  When  a  pop-up  menu  is  displayed,  the  location  cursor  shall  be  positioned  on  the  first 
available  option  in  the  menu. 

5.  <Select>  or  <Menu>  shall  select  a  menu  option  and  dismiss  the  menu. 

6.  <Shift>  +  <F10>  (and  <Menu>)  shall  display  a  pop-up  menu. 

7.  Arrow  keys  shall  move  the  location  cursor  between  available  options  in  a  pop-up  menu. 

8.  <Retum>,  <Enter>,  or  <Space>  (and  <Select>)  shall  select  an  option  and  shall  dismiss  a 
pop-up  menu. 

9.  When  an  option  is  selected  with  a  pointing  device  or  keyboard,  the  pop-up  menu  shall  be 
dismissed. 

10.  Cancel  and  <Shift>  +  <F10>  (and  <Menu>)  shall  dismiss  a  pop-up  menu  without  making 
a  selection. 


Source 

CSFAB,  TBM,  DISA,  MSWUE. 
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14.7.2  Pull-down  menus 


Menu  titles 


Menu  items 


Figure  25:  Example  of  a  standard  pull-down  menu. 

1.  Posted  menus  operations  shall  be  used  for  pull-down  menus.  In  posted  menus,  the  pull¬ 
down  menu  appears  when  the  operator  selects  a  pull-down  menu  title  and  remains  visible 
even  if  the  selector  is  released. 

2.  Pull-down  menus  shall  be  avoided  when  the  location  of  the  pull-down  menu  is  such  that 
it  may  cover  time  critical  information  such  as  tactical  plots. 

3.  An  application  shall  have  only  one  pull-down  menu  bar  that  is  displayed  upon  entering 
the  application  and  only  removed  when  the  application  is  closed. 

4.  Hard  keys  and  controls  (such  as  hard  range  keys)  shall  be  redundantly  placed  in  the  pull¬ 
down  menus. 

5.  A  pull-down  menu  shall  consist  of  a  menu  bar,  titles  and  a  set  of  options  or  commands 
below  each  title.  The  menu  bar  shall  be  located  along  the  top  margin  of  a  window. 

6.  Book  title  capitalization  shall  be  used  in  the  menu  item  text. 

7.  Each  menu  title  shall  have  an  associated  pull-down  menu  that  contains  groups  of  options. 
Each  option  shall  include  a  unique  mnemonic  access  key. 

8.  The  menu  shall  be  wide  enough  to  accommodate  a  tool  bar  icon,  the  wording  of  the 
longest  menu  option,  and  a  keyboard  accelerator. 

9.  A  minimum  of  five  spaces  shall  be  provided  between  the  icon,  the  option,  and  the 
accelerator  so  each  can  be  easily  distinguished  by  the  user. 

10.  Menu  items  that  are  arranged  in  columns  or  accessed  by  scrolling  shall  not  be  used. 

Source 


CSFAB,  MSWUE. 
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14.7.3 


Option  menus 


1.  An  option  menu  shall  be  used  to  make  a  mutually  exclusive  selection  from  a  list  of 
options.  Option  menus  are  helpful  in  that  users  do  not  have  to  type  in  data,  remember 
codes,  and  thus  the  users  make  fewer  data  entry  errors. 

2.  The  options  in  an  option  menu  may  include  mnemonics  but  do  not  include  keyboard 
accelerators. 

3.  Posted  methods  shall  be  used  with  the  S  button  to  display  an  option  menu. 

4.  When  an  option  menu  is  displayed,  the  location  cursor  shall  be  on  the  previously  selected 
option. 

5.  Spring-loaded  and  posted  methods  shall  be  used  with  the  S  button  to  navigate  within  and 
make  selections  in  the  option  menu. 

6.  When  an  option  is  selected  in  an  option  menu,  it  shall  appear  as  the  label  in  the  option 
menu  button. 

7.  Either  <Space>  or  <Select>  shall  display  an  option  menu. 

8.  Arrow  keys  shall  move  the  location  cursor  between  available  options  in  an  option  menu. 

9.  <Retum>,  <Enter>,  or  <Space>  shall  select  an  option  and  dismisses  an  option  menu.  If 
the  keyboard  has  a  <Select>  key,  it  shall  also  select  an  option  and  dismiss  the  option 
menu. 

10.  Cancel  shall  dismiss  an  option  menu  without  making  a  selection. 

1 1 .  Options  shall  normally  be  listed  in  alphabetical  or  numeric  order  but  other  groupings  may 
be  more  suitable  for  specific  tasks. 

12.  If  the  operator  must  scan  the  option  list  and  determine  a  proper  option,  the  list  shall  be 
limited  to  nine  options. 

13.  The  number  of  options  shall  only  be  limited  to  the  display  size  if  the  operator  is  looking 
for  a  known  specific  value. 

14.  If  the  number  of  options  cannot  be  displayed  simultaneously  on  the  display  then  either  a 
scrolling  option  menu  or  a  list  box  shall  be  used. 

15.  If  more  than  50  options  are  available,  a  combination  text  box  and  list  box  shall  be  used. 

16.  Option  menus  shall  use  first  character  speed  search. 

17.  The  display  and  operation  of  option  menus  shall  follow  the  Microsoft  Windows 
conventions. 


Source 
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CSFAB,  TBM,  MSWUE. 


14.7.4  Cascading  Submenus 

1.  Cascading  submenus  shall  appear  to  the  right  of  the  parent  menu  and  to  the  left  if  the 
space  to  the  right  is  limited. 

2.  Cascading  submenus  shall  be  limited  to  two  levels  (one  level  below  the  main  pull  down 
menu). 

3.  Cascading  submenus  shall  not  repeat  the  parent  option  as  the  first  option  in  the  submenu. 

4.  The  submenu  shall  be  positioned  so  the  first  option  is  aligned  with  the  right-pointing 
arrow  in  the  parent  option  for  the  submenu. 

5.  Cascading  menus  are  most  useful  to  display  user  access  to  additional  choices  rather  than 
using  more  space  in  the  parent  menu.  Cascading  menus  shall  not  be  used  for  frequent  or 
repetitive  commands. 


Source 

CSFAB,  TBM,  DISA,  MSWUE. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  ease  of  use  and  design  consistency  of  all  menus  used  in  the  OMI. 

Operator  performance: 

•  Objective  assessment  of  use  and  usefulness  of  menus  through  usability  testing. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  perceptions  of  usability,  utility,  and 
consistency  of  menus  in  the  OMI  and  ESS. 

Relationship  to  other  guidelines 

15  Windows  states,  components,  and  operations 
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15  Windows  states,  components,  and  operations 


15.1  Overview 

Windows  are  used  to  show  separate  applications  or  groups  of  information  on  the  same  screen. 
They  can  be  manipulated  to  best  display  the  required  information  to  solve  the  problem  at  hand. 
However,  certain  windows  in  combat  systems  need  to  be  in  fixed  locations  to  ensure  the  operator 
can  quickly  and  easily  find  important  information.  Windows  are  always  arranged  in  a  hierarchy 
with  the  root  window  being  the  parent  of  all  windows.  Any  time  a  window  is  invoked,  it  becomes 
the  child  of  the  window  from  which  it  is  called. 

15.2  Window  states 

15.2.1  Window  state  characteristics 

1.  Windows  must  always  be  in  one  of  three  states:  Open,  Minimized,  or  Closed. 

2.  Multiple  windows  may  be  open  at  any  one  time  and  may  partially  obscure  other  windows 
provided  the  obscured  window  is  not  a  fixed  window. 

3.  An  active  window  that  does  not  need  to  be  kept  open  may  be  minimized.  A  minimized 
window  shall  be  replaced  by  a  button  that  shall  be  located  on  the  taskbar. 

4.  Minimizing  a  window  and  the  behaviour,  appearance,  and  manipulation  of  minimized 
windows  shall  be  consistent  with  Microsoft  Windows  styles. 

5.  When  a  window  is  closed,  it  shall  be  removed  from  the  screen  and  normally  its  children 
windows  shall  be  closed. 

6.  An  application  shall  assign  focus  to  another  window  in  the  application  (e.g.,  the  parent 
window)  when  the  application  window  with  input  focus  is  closed. 

7.  The  effect  on  children  windows  of  closing  windows  shall  be  consistent  with  Microsoft 
Window  styles. 

8.  Open  or  minimized  windows  shall  be  considered  to  be  active  if  processing  is  occurring  in 
the  window.  Windows  do  not  have  to  have  input  focus  to  be  active.  A  window  without 
input  focus  may  also  be  active,  as  long  as  processing  in  the  window  continues.  The 
content  of  an  active  window  continues  to  update  even  if  the  window  loses  input  focus. 

9.  The  window  that  receives  keyboard  events  is  said  to  have  the  input  focus  and  is  always 
open. 

10.  A  window  is  in  the  open  state  when  it  is  on  the  screen.  Multiple  windows  shall  be 
allowed  to  be  open  at  any  time. 

1 1.  A  window  shall  be  active  when  it  has  input  focus. 
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12.  A  window  shall  have  input  focus  when  it  first  appears  on  the  screen  if  the  window  was 
launched  in  response  to  a  user’s  request. 

13.  When  a  window  is  minimized,  it  shall  be  replaced  by  a  button  and  any  processing  that 
was  occurring  in  the  window  continues. 

14.  When  a  window  is  closed  it  shall  be  removed  from  the  screen  and  processing  that  was 
occurring  in  the  window  shall  stop.  Exceptions  include  the  following:  Windows  where 
background  processes,  message  transmission,  and  database  updates  are  occurring. 

15.  When  a  window  with  input  focus  is  closed,  the  focus  is  set  to  the  previous  window  that 
had  the  focus. 

Source 

CSFAB,  TBM,  D1SA,  MSWUE,  UCA. 

Discussion 

G2.  This  provision  was  edited  for  Maritime  operations  so  that  no  window  may  completely 

obscure  other  windows. 

G12.  This  guidance  was  amended  to  ensure  that  any  change  in  focus  is  under  the  control  of  the 

user. 

15.2.2  Minimized  windows 

1 .  A  minimized  window  shall  have  the  same  title  as  its  corresponding  window. 

2.  A  minimized  window  title  shall  be  the  same  width  as  the  minimized  window  entry;  the 
title  may  be  truncated  to  fit. 

3.  When  the  location  cursor  appears  on  the  minimized  window,  the  full  window  title  shall 
be  displayed. 

4.  When  the  location  cursor  is  not  on  a  minimized  window,  the  title  shall  be  truncated  to  the 
same  width  as  the  minimized  window  button. 

5.  The  minimized  window  menu  shall  have  the  same  options  as  the  Window  Menu  for  the 
corresponding  window,  but  not  all  options  shall  be  available  for  selection  (see  MSWUE 
for  details  regarding  minimized  window  menu  options). 

6.  To  display  the  minimized  window  Menu,  users  shall  click  the  M  button  (the  right  button) 
on  the  minimized  window. 

7.  To  dismiss  the  minimized  window  Menu,  users  shall  click  the  M  or  S  button  anywhere 
outside  the  menu. 


Source 

TBM,  D1SA,  MSWUE. 


DRDC  Toronto  TR  2009-062 


147 


15.3  Window  components 


Menu 

Bar 


Vertical 

scroll 

bar 


Figure  26:  Illustrations  of  the  standard  window  components  (e.g.,  title  bar,  window  menu, 
minimize/maximize/ close  buttons)  residing  within  the  primary  window  as  discussed  in  Sections 

15.3.2,  15.3.3,  and  15.3.4. 


15.3.1  Window  component  characteristics 

1.  All  windows  shall  consist  of  two  principle  areas:  a  window  frame  and  an  application  or 
client  area. 

2.  The  contents  of  the  window  frame  differ  by  window  type  but  the  frame  may  contain  a 
title  bar,  resize  border,  window  menu  button,  and  title  bar  buttons.  The  exact  function  of 
each  object  shall  be  a  function  of  whether  the  window  is  a  root  (system),  primary 
(application),  or  secondary  (file)  window. 

3.  A  resize  border  shall  allow  the  operator  to  alter  the  size  of  the  window. 
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Source 


CSFAB,  TBM. 

15.3.2  Titlebar 

1 .  A  window  title  shall  appear  in  the  title  bar  of  a  window. 

2.  The  title  shall  be  left  justified  in  the  title  bar  and  presented  in  mixed-case  letters.  The  first 
letter  of  each  significant  word  in  a  title  and  acronyms  shall  be  capitalized  (e.g.,  Office 
Sym,  Exit). 

3.  If  a  title  is  not  yet  defined  a  default  of  Untitled  shall  be  used. 

4.  The  title  shall  match  or  at  least  contain  the  wording  from  the  icon,  menu,  button,  or  other 
action  that  invoked  the  window. 

5.  Each  display  shall  be  labelled  with  a  title  or  label  that  is  unique  within  the  system.  To 
make  the  display  as  meaningful  as  possible  and  to  reduce  user  memory  requirements, 
every  field  or  column  heading  shall  be  labelled. 

6.  If  an  application  has  multiple  primary  task  windows,  each  title  shall  indicate  the  window 
puipose  and  includes  the  application  name  separated  by  a  dash  (-). 


Source 

CSFAB,  TBM,  D1SA. 

15.3.3  Title  bar  buttons 

1.  The  Microsoft  Windows  styles  shall  be  followed  for  the  design  and  implementation  of 
title  bar  buttons,  controls,  icons,  and  locations. 

2.  A  Minimize  button  shall  reduce  the  application  to  its  smallest  size. 

3.  For  primary  windows,  minimizing  removes  the  window  from  the  screen  and  the  window 
shall  appear  as  a  button  on  the  taskbar. 

4.  A  Restore/Maximize  button  shall  be  a  toggle  button  consistent  with  the  Microsoft 
Windows  styles.  The  button  shall  show  the  Maximize  icon  and  shall  enlarge  the  window 
to  its  largest  size  when  selected.  If  the  window  is  already  maximized,  the  button  shall 
show  the  Restore  icon  and  shall,  when  selected,  restore  the  window  to  its  previous  size. 

5.  The  order  of  the  shortcut  buttons  on  the  title  bar  shall  be  in  the  following  order  from  left 
to  right  with  the  close  button  in  the  right-hand  edge  of  the  title  bar:  Minimize, 
Restore/Maximize,  Close. 

6.  Context-sensitive  Flelp  buttons  shall  be  designed  and  implemented  in  accordance  with 
Windows  styles.  When  applicable,  context-sensitive  help  buttons  are  displayed  as  the 
left-most  button  of  the  shortcut  buttons  on  the  title  bar. 
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Source 


CSFAB,  MSWUE. 

15.3.4  Window  menu  bar 

1 .  If  a  window  includes  a  menu  bar,  it  shall  be  located  below  the  title  bar. 

2.  The  menu  bar  shall  contain  no  more  than  ten  menu  titles  plus  Help. 

3.  The  menu  titles  shall  begin  at  the  left  margin  and  extend  to  the  right. 

4.  Each  menu  title  shall  include  a  mnemonic. 

5.  Options  in  application  menus  shall  not  duplicate  functionality  that  is  available  in  the 
system  menu. 

6.  A  menu  shall  have  the  same  title  and  options  when  it  is  in  an  application  menu  bar. 

Source 
TBM,  D1SA 

15.3.5  Window  menu  button 

1 .  The  window  menu  button  shall  provide  access  to  a  pull-down  menu  that  may  contain  the 
following  window  management  options:  Restore,  Move,  Size,  Minimize,  Maximize,  and 
Close  (see  Table  5,  below,  for  a  table  presenting  window  menu  titles  and  functions). 


Table  5:  Window  menu  options  and  operations 


Window  Menu 

A  window  menu  is  used  to  display  a  list  of  window  actions.  The  window  menu 
button  is  located  in  the  upper-left  comer  of  every  window.  Pressing  the 
window  menu  button  activates  the  menu  and  presents  the  following  options: 
Restore,  Move,  Size,  Minimize,  Maximize,  and  Close. 

Restore 

The  Restore  option  restores  the  minimized  or  maximized  window  to  the 
previous  size  and  location. 

Move 

The  Move  option  moves  a  window  around  the  workspace. 

Size 

The  Size  option  changes  the  height  and  width  of  the  window  in  the  direction 
indicated  by  the  pointer. 

Minimize 

The  Minimize  option  minimizes  a  window  to  its  smallest  size. 

Maximize 

The  Maximize  option  enlarges  a  window  to  its  maximum  size. 
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Close 


The  Close  option  closes  a  window  and  removes  it  from  the  workspace. 


COMDAT  OMI  Style  Gui 


) 

Move 

Size 

_  Minimize 
□  Maximize 


X  Close  Alt+F4 


Figure  27:  Window  pull-down  menu. 

2.  If  any  of  the  Window  Menu  options  are  not  available  for  a  certain  window,  those  options 
shall  be  disabled. 

3.  Additional  Window  Menu  button  options  may  be  provided.  If  so,  they  shall  be  placed 
before  the  Close  options. 

4.  For  fixed  windows  without  title  bars,  the  Window  Menu  shall  contain  Window 
Information  as  the  first  option  in  the  menu.  This  option  will  provide  a  window  containing 
all  relevant  window  information  that  is  missing  because  of  the  lack  of  a  title  bar  or 
message  bar  in  the  fixed  window. 

5.  Double  clicking  on  the  Window  Menu  button  shall  perform  the  close  command. 

6.  Navigation  and  selection  in  the  Window  Menu  shall  be  done  as  in  a  pull-down  menu. 

7.  In  addition  to  using  the  Window  Menu  users  can  execute  mnemonics  or  keyboard 
accelerators  to  select  manipulation  options  (see  MSWUE  for  keyboard  accelerators). 


Source 

CSFAB,  TBM,  MSWUE. 

Discussion 

OSF/Motif  and  Microsoft  Windows  handle  window  menu  functions  differently.  The  differences 
include  how  the  minimized  windows  are  displayed  and  the  actions  taken  on  them.  Developers 
should  consult  MSWUE  for  details  regarding  the  window  menu.  Throughout  this  section  the 
sources  for  the  specification  are  cited,  however  the  specifications  have  been  edited  to  be 
consistent  with  MSWUE. 

15.3.6  Optional  window  properties 

1.  A  message  bar  is  an  optional  window  component  that  can  be  used  at  the  discretion  of  the 
designer.  A  message  bar  is  a  place  to  display  non-critical  application  messages.  A 
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message  bar  shall  not  be  used  to  display  messages  requiring  immediate  action  by  the 
operator. 

2.  A  footer  bar  can  be  used  to  display  defined  function  keys,  function  icons,  or  application 
settings  information.  However,  function  icons  shall  be  made  available  in  the  upper  tool 
bars  if  space  permits. 

3.  A  footer  bar  is  space  efficient  if  a  horizontal  scroll  bar  is  used.  The  footer  bar  can  be 
located  to  the  left  of  the  horizontal  scroll  bar,  as  the  scroll  bar  does  not  require  the  entire 
client  area  width. 

4.  A  pane  or  separator  provides  two  application  areas  in  one  window.  This  is  used  to  allow 
the  operator  to  view  two  different  parts  of  the  window  simultaneously.  The  pane  or 
separator  divides  the  application  area  either  vertically  or  horizontally.  Initially  the 
application  area  is  divided  in  half  but  the  operator  shall  be  able  to  move  the  pane  to  adjust 
this  division. 


Source 

CSFAB,  UCA. 

15.4  Windows  operations 

15.4.1  Moving  a  window 

1.  To  move  a  window,  users  shall  select  the  Move  option  in  Window  Menu,  and  then  drag 
the  window  to  new  location.  An  outline  of  the  window  shall  move  on  the  screen  as  the 
user  moves  the  pointer. 

2.  To  move  a  window,  users  shall  select  the  title  bar  and  then  drag  the  window  to  the  new 
location.  An  outline  of  the  window  shall  move  on  the  screen  as  the  user  moves  the 
pointer. 

3.  A  window  shall  not  be  allowed  to  be  moved  to  a  position  such  that  parts  of  the  window 
leave  the  display  area. 

4.  Windows  shall  be  moved  between  multiple  display  surfaces  by  dragging  the  window 
from  one  display  to  the  other. 
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Source 


CSFAB,  TBM,  MS1472F. 

15.4.2  Opening  and  closing  windows 

1 .  When  a  window  is  closed  and  then  reopened,  it  shall  be  displayed  where  it  was  when  it 
was  closed. 

2.  To  close  a  window,  users  shall  select  the  Close  option  in  the  Window  Menu  or  select  the 
Close  button  and  the  window  shall  close.  Users  shall  be  prompted  to  save  any  unsaved 
data. 

3.  Closing  a  window  removes  it  from  the  display  and  ceases  all  processing  in  that  window. 
If  processing  is  occurring  or  unsaved  data  has  been  generated,  users  shall  be  required  to 
confirm  the  action  before  the  window  is  removed  from  the  screen  and  processing  stops. 

4.  Upon  closing  a  window,  automatic  saving  may  be  used  instead  of  user  confirmation  if 
saving  is  always  desired. 


Source 

CSFAB,  TBM. 

15.4.3  Sizing  windows 

1.  To  resize  a  window,  users  shall  select  the  Size  option  in  the  Window  Menu,  and  then 
drag  the  frame  to  the  new  size.  An  outline  of  the  window  shall  move  on  the  screen  as  the 
user  moves  the  pointer. 

2.  To  resize  a  window,  users  shall  press  the  S  or  T  button  when  the  cursor  is  over  the 
window  frame,  and  then  drag  it  to  the  new  size.  An  outline  of  the  window  shall  move  on 
the  screen  as  the  user  moves  the  pointer. 

3.  When  a  window  is  resized,  only  the  window  borders  (not  the  size  of  objects)  shall  be 
changed/resized. 

4.  When  a  window  is  resized,  the  relative  position  of  objects  in  the  window  shall  not 
change. 

5.  The  contents  of  the  window  shall  remain  visible  during  resizing  so  users  can  view  the 
effect. 

6.  Florizontal  and  vertical  scroll  bars  shall  appear  as  appropriate  when  a  window  is  resized. 

7.  Resizing  a  window  smaller  is  limited  to  a  predefined  minimum  size  so  that  objects  are  not 
obscured  when  the  window  is  at  its  minimum  size. 

8.  Resizing  a  window  larger  is  limited  so  that  the  system-level  classification  and  menu  bar 
shall  not  be  obscured  by  the  window  at  maximum  size. 


DRDC  Toronto  TR  2009-062 


153 


9.  All  window  types  shall  be  capable  of  being  resized  larger  only  if  more  information  can  be 
displayed  by  resizing. 

10.  A  window  will  only  be  permitted  to  be  resized  in  the  direction  that  displays  more 
information. 

1 1.  A  dialog  window  shall  not  be  resized  any  smaller  than  its  default  size. 

12.  Users  shall  be  able  to  resize  an  application  window  that  covers  the  entire  screen. 

13.  Windows  shall  be  sized  so  that  all  objects  in  it  are  visible  when  the  window  first  appears. 

14.  At  a  minimum,  a  window  shall  be  wide  enough  to  read  the  title  and  tall  enough  to  read 
the  title  and  menu  bar. 


Source 
TBM,  D1SA. 

Discussion 

G3.  Exceptions  to  this  design  rule  include  objects  in  graphs  (e.g.,  lines,  bars,  etc.),  lists  or 
graphic  schedules.  As  a  window  is  resized,  these  objects  may  want  to  be  resized  along  with  the 
window  and  lists  and  text  areas. 

G4.  Exceptions  to  this  design  rule  include  objects  in  graphs  (e.g.,  lines,  bars,  etc.)  or  graphic 
schedules.  As  a  window  is  resized,  these  objects  may  need  to  be  resized  along  with  the  window. 
Other  exceptions  might  include  a  window  that  contains  a  scrolled  list  widget  where  the  list  is 
stretched  when  the  window  is  resized  larger. 

G10.  If  a  window  contains  a  list  widget  and  more  information  can  be  displayed  by  resizing  the 
window  in  a  vertical  direction  then  the  window  will  not  permit  the  user  to  resize  it  larger  in  a 
horizontal  direction  since  no  new  information  is  displayed  in  this  direction.  However,  the  user 
shall  still  be  able  to  make  the  window  smaller. 

15.4.4  Restore,  minimize,  and  maximize  windows 

1.  To  minimize  a  window,  users  shall  select  the  Minimize  button  on  the  Title  Bar  or  the 
Window  Menu.  The  window  shall  be  minimized  and,  for  primary  windows,  its  entry  shall 
appear  on  the  taskbar. 

2.  To  restore  a  minimized  window,  users  shall  click  the  S  button  on  the  entry  of  the 
minimized  window. 

3.  To  maximize  the  size  of  a  window,  users  shall  select  the  Maximize  button  on  the  Title 
Bar  or  the  Window  Menu  and  the  window  shall  expand  to  its  full  size. 

4.  To  restore  a  window  to  its  previous  size,  users  shall  select  the  Restore  option  in  the 
Window  Menu  or  the  Restore  button  and  the  window  shall  be  restored  to  its  previous 
size. 
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5.  The  default,  maximum,  and  minimum  size  of  each  window  shall  be  defined  in  the 
application. 

6.  When  resized,  the  graphics  in  the  window  may  remain  the  same  size,  or  may  be  rescaled 
to  fit  the  new  window  size.  This  is  determined  by  the  task  requirements.  If  the  window 
display  is  clipped,  the  upper-left  comer  information  shall  remain  in  the  upper-left  comer 
in  the  newly  sized  window. 

7.  A  minimum  size  for  a  window  may  be  specified.  Otherwise,  the  window  shall  be  tall 
enough  to  display  the  title  bar,  classification  bar,  and  menu  bar.  The  window  shall  be 
wide  enough  to  display  the  window  menu  button,  window  title,  and  the  minimize  and 
maximize  buttons. 

8.  The  design  may  specify  a  maximum  size  for  a  window;  otherwise,  the  maximum  size 
shall  be  determined  by  the  operational  requirements. 


Source 

CSFAB,  TBM,  MSWUE. 

15.4.5  Window  placement 

1.  A  window  shall  be  displayed  at  the  same  location  where  it  was  when  last  closed  or 
minimized. 

2.  Initially,  a  window  shall  be  placed  so  important  information  is  at  the  centre  of  the  users' 
visual  focus. 

3.  Initially,  a  window  shall  be  placed  so  important  information  is  not  obscured. 

4.  Initially,  a  window  shall  be  placed  so  the  amount  of  pointer  movement  to  execute  an 
operation  is  minimized. 

5.  Initially,  a  dialog  window  shall  be  placed  to  the  right  of  the  information  to  which  it 
relates. 

6.  A  gradual  stepping  alignment  shall  be  used  to  display  multiple  non-modal  dialog  boxes 
that  are  spawned  from  an  application.  This  will  prevent  new  dialog  boxes  from  appearing 
on  top  of  each  other.  Each  dialog  box  can  be  located  in  a  position  that  is  slightly 
downward  and  to  the  right. 

7.  Secondary  and  dialog  windows  shall  not  open  initially  in  a  comer  of  the  screen  (e.g.,  top 
left  comer). 

8.  A  default  location  and  size  shall  be  specified  for  each  window  when  it  first  appears  on  the 
display.  The  system  shall  provide  the  user  the  option  of  changing  the  default  to  the 
present  size  and  location.  The  system  shall  provide  the  ability  to  revert  to  the  system 
default. 


Source 
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CSFAB,  TBM,  DISA. 


Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  ease  of  use  and  design  consistency  of  all  windows  used  in  the  OMI. 

Relationship  to  other  guidelines 

10  Windows 

1 1  Window  design  guidance 

12  Windows  navigation  and  selection 
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16  Security  and  Simulation 


16.1  Security  and  simulation  characteristics 

16.1.1  System  security 

1 .  Data  shall  be  protected  from  unauthorized  use,  potential  loss  from  equipment  failure,  and 
user  errors. 

2.  Automated  measures  shall  be  provided  to  minimize  data  loss  from  intruders  in  a  system 
or  from  errors  by  legitimate  users. 

Source 


MS1472F. 


16.1.2  System  simulation 

1 .  When  simulated  data  and  system  functions  are  provided  real  data  shall  be  protected  and 
real  system  use  shall  be  clearly  distinguished  from  all  simulated  operations. 

2.  In  applications  where  either  real  or  simulated  data  can  be  displayed,  a  clear  indication  of 
simulated  data  shall  be  included. 


Source 

MS1472F. 

Discussion 

G2.  MS1472F  requires  that  the  indication  of  simulated  data  shall  be  displayed  as  part  of  the 

classification  label. 


16.2  System  login 

Login  windows,  (e.g.,  Figure  28),  can  be  implemented  to  restrict  access  to  sensitive  applications. 
As  a  minimum,  the  login  window  contains  two  text  fields:  one  for  entering  a  user  name  and  one 
for  a  password.  For  security  purposes,  asterisks  are  displayed  for  each  password  character 
entered. 
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Figure  28:  Example  of  a  login  window. 

1 .  Where  two  or  more  users  must  have  simultaneous  access  to  the  computer  program  or  data 
processing  results  from  multiple  personal  equipment  interfaces,  the  operation  by  one 
person  shall  not  interfere  with  the  operations  of  another  person  unless  mission  survival 
may  be  contingent  upon  pre-emption. 

2.  Provisions  shall  be  made  so  that  a  pre-empted  user  can  resume  operations  at  the  point  of 
interference  without  information  loss. 

3.  Users  shall  complete  a  login  procedure  before  the  system  functions  can  be  accessed. 

4.  In  applications  where  users  must  login  to  the  system,  login  shall  be  a  separate  procedure 
that  must  be  completed  before  a  user  is  required  to  select  among  any  operational  options. 

5.  Users  shall  be  provided  with  feedback  relevant  to  the  login  procedure;  the  feedback  shall 
indicate  the  status  of  the  inputs. 

6.  A  system  shall  provide  access  to  only  those  applications  to  which  a  user  is  allowed 
access. 

7.  Operators  must  be  able  to  login  in  any  operational  role  so  as  to  assume  any  role  within 
the  operations  room  as  required. 

8.  If  appropriate,  users  shall  also  complete  a  login  for  individual  or  groups  of  applications. 

9.  If  the  system  is  unavailable,  a  message  shall  be  displayed  indicating  the  system  status  and 
when  the  system  will  be  available. 

10.  If  a  user  cannot  login  to  a  system,  a  prompt  shall  be  provided  to  explain  the  reason  for 
this  inability. 

1 1 .  Login  processes  shall  require  minimum  input  from  the  user  consistent  with  the 
requirements  prohibiting  illegal  entry. 

12.  A  login  window  shall  be  displayed  on  the  screen  when  users  begin  a  session  on  a  system. 

13.  Appropriate  prompts  for  login  shall  be  automatically  displayed  on  the  user's  terminal  with 
no  special  action  required  other  than  turning  on  the  terminal. 

14.  A  login  window  shall  contain  two  text  fields,  one  each  for  entering  user  identification  and 
password. 
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15.  User  identification  procedures  shall  be  as  simple  as  possible,  consistent  with  adequate 
data  protection. 

16.  The  password  shall  not  be  echoed  on  the  display.  An  asterisk  (*)  shall  be  displayed  for 
each  character  when  inputting  secure  passwords  during  login. 

17.  When  passwords  are  required,  users  shall  be  allowed  to  choose  their  own  passwords  since 
a  password  chosen  by  a  user  will  generally  be  easier  for  that  individual  to  remember. 
Guidelines  for  password  selection  shall  be  given  so  that  users  will  not  choose  easily 
guessable  ones. 

18.  Users  shall  be  allowed  to  change  passwords  whenever  they  choose;  all  passwords  shall  be 
changed  at  periodic  intervals  (not  to  exceed  six  months). 

19.  The  text  fields  shall  not  provide  cues  as  to  the  number  of  characters  required  for  a 
password. 

20.  The  layout  and  format  of  objects  in  the  login  window  shall  have  the  system  title  or  logo 
centred  at  the  top.  The  login  name  and  password  fields  shall  be  on  two  separate  lines 
below  the  title.  The  window  shall  have  button  controls  at  the  bottom  that  shall  include,  at 
minimum,  the  Login  button  in  addition  to  the  usual  controls. 

21.  Users  shall  enter  a  valid  identification  and  password  before  a  session  is  initiated. 

22.  If  an  invalid  identification  and/or  password  is  entered,  an  error  message  shall  be 
displayed. 

23.  Users  who  fail  repeatedly  to  login  shall  be  locked  out  of  the  system  and  informed  that 
they  must  contact  the  system  administrator. 


Source 

CSFAB,  TBM,  D1SA,  MS1472F,  UCA. 

Discussion 

As  much  as  possible,  a  login  procedure  should  not  be  required  in  Canadian  Maritime  CCSs  for 
operators.  Login  procedures  may  be  implemented  in  order  to  track  training  or  for  record-keeping. 
Before  requiring  login  procedures  to  be  implemented,  the  project  office  should  consider  the 
consequences  within  the  operational  context.  An  example  of  a  negative  operational  consequence 
is  the  potential  for  a  delay  while  an  operator  performs  the  login,  thus  impeding  a  hot  swap. 

G17.  Before  requiring  passwords  as  part  of  the  login  procedure,  the  extent  of  security  measures 

required  should  be  determined. 

16.3  System  logout 

1 .  To  terminate  a  session,  users  shall  select  logout  from  the  system  menu. 

2.  Users  shall  be  prompted  to  save  data  prior  to  logout  if  there  is  any  unsaved  data. 
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3.  Users  shall  be  prompted  to  logout  of  any  applications  that  required  they  login. 

4.  During  logout,  all  processing  in  application  windows  shall  stop,  and  all  windows  shall  be 
closed,  with  the  exception  of  the  CCS  window. 

5.  When  logout  is  complete,  the  initial  login  window  shall  be  displayed. 

6.  If  there  is  auto  logout,  the  system  shall  incorporate  the  standard  length  of  user  inactivity 
before  logout  occurs. 

7.  Users,  or  the  system  administrator,  shall  be  permitted  to  modify  the  time  before  auto 
logout  occurs. 

8.  A  message  is  displayed  during  inactivity  indicating  the  action  needed  to  avoid  auto 
logout. 

9.  For  auto  logout,  unsaved  data  shall  be  saved,  with  a  message  indicating  logout  and  file 
name. 

10.  If  a  partial  hardware/software  failure  occurs,  the  program  shall  allow  for  orderly 
shutdown  and  establishment  of  a  checkpoint  so  restoration  can  be  accomplished  without 
loss  of  computing  performed  to  date. 


Source 

TBM,  D1SA,  MS1472F,  UCA. 

Discussion 

G4.  The  logout  procedure  normally  closes  all  application  windows,  even  the  CCS  application. 
UCA  added  the  caveat  that  the  CCS  application  shall  not  be  closed  upon  logout. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  ease  of  use  and  design  consistency  of  security  procedures  used  in  the  OM1. 


160 


DRDC  Toronto  TR  2009-062 


17  Data  display  and  entry 


17.1  Data  display  and  entry  characteristics 

1 .  The  design  of  each  window  shall  be  consistent  with  the  task  being  performed  by  users. 

2.  If  push  buttons  are  used  in  a  data  entry  window,  they  shall  be  separate  from  the  main 
body  of  the  window  and  shall  be  located  at  the  bottom  of  the  window. 

3.  If  the  data  extend  across  several  pages,  related  data  shall  be  placed  on  the  same  page. 

4.  The  format  for  the  data  display  shall  be  compatible  with  the  format  used  for  data  entry. 

5.  When  users  work  from  a  hard  copy  form,  the  window  foimat  shall  have  an  identical 
format,  unless  a  tailored  soft  version  is  demonstrably  more  effective. 

6.  Default  values  shall  be  used  to  reduce  user  workload.  Defined  default  values  shall  be 
displayed  automatically  in  their  appropriate  data  fields  with  the  initiation  of  a  data  entry 
transaction  and  the  user  shall  indicate  acceptance  of  the  default. 

7.  The  user  shall  be  able  to  replace  any  default  value  during  a  given  transaction  without 
changing  the  default  definition. 

8.  Where  a  series  of  default  values  have  been  defined  for  a  data  entry  sequence,  the 
experienced  user  shall  be  allowed  to  default  all  entries  or  to  default  until  the  next  required 
entry. 

9.  Field  labels  shall  be  distinctively  presented  such  that  they  can  be  distinguished  from  data 
entry.  Labels  for  data  entry  fields  shall  incorporate  additional  cueing  of  data  foimat 
where  the  entry  is  made  up  of  multiple  inputs. 


Source 

TBM,  MS1472F. 

17.2  Data  entry  and  manipulation 

17.2.1  Data  entry  and  manipulation  characteristics 

1.  Data  entry  shall  be  consistent  with  the  Microsoft  Windows  styles. 

2.  A  data  entry  window  shall  include  a  title  that  describes  the  contents  of  the  window. 

3.  Display  formats  shall  be  consistent  within  a  system.  When  appropriate  for  users,  the  same 
format  shall  be  used  for  input  and  output.  Data  entry  formats  shall  match  the  source 
document  formats. 
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4.  Data  entry  functions  shall  be  designed  to  establish  consistency  of  data  entry  transactions, 
minimize  input  actions  and  memory  load  on  the  user,  ensure  compatibility  of  data  entry 
with  data  display,  and  provide  flexibility  of  user  control  of  data  entry. 

5.  Data  entry  shall  be  paced  by  the  user,  rather  than  by  the  system. 

6.  The  same  set  of  actions  to  enter  and  manipulate  data  shall  be  used  throughout  the 
application. 

7.  The  system  shall  provide  a  positive  feedback  to  the  user  of  the  acceptance  or  rejection  of 
entered  data,  if  appropriate. 

8.  Feedback  shall  be  provided  which  presents  status  information,  confirmation,  and 
verification  throughout  the  interaction. 

9.  If  the  system  rejects  a  user  input,  feedback  shall  be  provided  to  indicate  the  reason  for 
rejection  and  the  required  corrective  action.  Feedback  shall  be  self-explanatory. 

10.  Editing  commands  such  as  Cut,  Copy,  and  Paste  shall  be  available  if  these  commands 
shall  facilitate  the  text  entry  process. 

1 1 .  The  default  for  text  entry  shall  be  insert  mode. 

12.  When  variable  length  information  is  entered  in  a  text  field,  it  shall  be  automatically 
justified.  Text  shall  be  left  justified.  Numeric  data  shall  be  justified  on  virtual  or  literal 
decimals. 

13.  Leading  characters  shall  not  be  required  to  fill  data  entry  space.  For  example,  if  a  text 
field  has  a  maximum  length  of  four  characters  and  the  user  wants  to  enter  the  number 
900,  the  system  shall  not  require  the  user  to  enter  0900.  The  leading  character  of  0  shall 
not  be  required  (except  as  necessary  for  compass  headings  or  similar  conventions). 

14.  Users  shall  be  able  to  enter  numeric  data  via  the  keyboard  and  the  numeric  keypad. 

15.  Users  shall  not  have  to  enter  the  unit  of  measurement  associated  with  a  numeric  value. 

16.  Data  shall  be  entered  in  units  that  are  familiar  to  the  user. 

17.  When  multiple  data  items  are  entered  as  a  single  transaction,  the  user  shall  be  allowed  to 
re-enter,  change,  or  cancel  any  item  before  taking  a  final  enter  action. 

18.  When  users  finish  making  entries  in  the  appropriate  data  fields  in  a  window,  they  shall 
enter  the  data  into  the  system  with  an  explicit  action  such  as  selecting  a  save  option. 

19.  A  data  entry  window  shall  contain  the  controls  needed  to  support  data  entry  and 
manipulation. 

20.  If  users  have  to  make  multiple  entries,  the  data  entry  window  shall  include  controls  to 
clear  the  window  and  restart  the  data  entry. 
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21.  Dialogue  types  (e.g.,  form  filling,  menus)  shall  be  compatible  with  anticipated  task 
requirements  and  user  skills. 

22.  Groups  of  data  shall  be  displayed  vertically,  not  horizontally,  although  columns  may  be 
used. 

23.  If  information  being  entered  in  a  text  field  is  a  known  fixed  length,  the  text  field  shall  be 
the  same  length. 

24.  If  the  length  of  information  being  entered  in  a  text  field  varies,  the  text  field  shall  be  as 
long  as  the  longest  possible  entry. 

25.  A  text  field  may  include  scroll  bars  if  space  in  the  window  is  limited. 

26.  The  text  field  shall  include  a  decimal  point  if  numeric  data  are  entered  in  decimal  format. 

27.  Field  formats  shall  be  consistent  with  users'  expectations  and  presented  in  meaningful 
chunks. 

28.  Data  that  are  known  or  can  be  computed  shall  be  automatically  entered  in  a  field. 

29.  Data  shall  not  be  entered  by  overwriting  a  set  of  characters  in  a  field  (such  as  a  default). 

30.  When  an  item  length  is  variable,  the  user  shall  not  have  to  remove  unused  underscores. 

3 1 .  Data  entry  fields  that  do  require  the  operator  to  enter  non-word  character  strings  over  four 
characters  shall  be  divided  into  equal  segments  of  no  more  than  four  characters  each.  If 
possible  the  groups  shall  be  equal  in  size  and  have  meaning  (e.g.,  time  HH:MM:SS). 

32.  Routine  or  default  data  shall  be  automatically  entered  in  a  field.  If  this  data  could  produce 
a  detrimental  effect,  it  shall  not  be  automatically  entered  or  must  be  confirmed  by  the 
operator. 

33.  Where  no  source  document  or  external  information  is  involved,  forms  shall  be  designed 
so  that  data  items  are  ordered  in  a  logical  sequence  for  input. 

34.  Form  filling  interactive  control  may  be  used  where  some  flexibility  in  data  to  be  entered 
is  needed  and  where  the  users  will  have  moderate  training.  A  form-filling  dialogue  shall 
not  be  used  when  the  system  must  handle  multiple  types  of  forms  and  the  system 
response  is  slow. 

35.  Displayed  forms  shall  be  arranged  to  group  related  items  together. 

36.  The  capability  shall  be  provided  to  label  and  store  frequently  used  text  segments,  forms, 
and  templates  (e.g.,  signature  blocks,  organizational  names,  call  signs,  coordinates),  and 
later  to  recall  (copy  into  current  text)  stored  segments  identified  by  their  assigned  labels. 

37.  Actions  that  affect  the  items  on  the  situation  display  (or  tactical  display)  shall  provide 
visual  feedback  to  the  operator  that  the  action  was  completed  as  intended. 
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38.  When  operators  access  information  in  order  to  alter  the  data,  the  window  shall  initially 
show  the  current  state  of  the  information. 

39.  Data  entry  shall  be  supported  by  standard  widgets  that  facilitate  data  entry  and  avoid 
keyboard  entry  by  the  operators.  Examples  include  widgets  such  as  spin  boxes  for 
numbers  and  calendars  for  dates. 

40.  Widgets  implemented  to  support  data  entry  (e.g.,  spin  boxes  for  numbers  and  calendars 
for  dates)  shall  not  replace  the  manual  entry  of  data. 

Source 

CSFAB,  TBM,  D1SA,  MS1472F,  MSWUE,  UCA. 

17.2.2  Pointer  control 

1.  The  text  pointer  shall  be  placed  and  moved  with  both  the  pointing  device  and  the 
keyboard. 

2.  When  a  window  has  input  focus,  the  text  pointer  shall  appear  in  the  text  area  where  the 
typing  is  most  likely  to  occur. 

3.  When  the  Select  button  is  clicked  in  an  empty  text  field,  the  text  pointer  shall  appear  at 
the  first  character  space  in  the  text  field  and  the  pointer  shall  remain  displayed  in  insert 
mode. 

4.  The  pointer  shall  disappear  from  the  screen  when  users  begin  typing  and  shall  reappear 
when  users  stop  typing  or  move  the  pointing  device. 

5.  The  pointer  shall  be  an  I-beam  shape  only  when  users  move  the  pointer  into  a  text  field 
where  text  entry  is  possible. 

6.  The  text  pointer  shall  only  be  allowed  to  be  placed  in  areas  where  text  entry  is  possible. 

7.  Text  entry  shall  not  be  possible  when  the  text  pointer  is  not  visible  and  shall  only  be 
possible  when  the  text  pointer  is  visible. 

8.  Applications  shall  ensure  that  the  text  pointer  is  highly  visible  when  it  appears  in  a  text 
entry  area. 

9.  When  the  pointer  is  on  non-editable  text,  its  shape  shall  not  change  to  an  I-beam. 

10.  Clicking  on  non-editable  text  shall  not  change  its  appearance  or  display  a  text  pointer. 

Source 

TBM,  D1SA,  MS1472F. 

17.2.3  Navigation 

1 .  Users  shall  move  the  text  cursor  between  single  line  text  fields  by  pressing  <TAB>. 
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2.  Applications  shall  not  automatically  tab  to  the  next  field. 

3.  When  the  text  pointer  is  tabbed  into  an  empty  text  field,  the  text  pointer  shall  appear  in 
the  first  character  space  at  the  left  end  of  the  text  field. 

4.  Users  shall  also  be  able  to  place  the  text  pointer  at  any  location  within  the  text  in  a  text 
field  by  positioning  the  pointer  and  pressing  the  Select  button. 

5.  The  size  of  the  text  pointer  shall  change  to  match  the  size  of  the  text  font  in  which  it  is 
placed. 

6.  In  a  multi-lined  text  field,  the  arrow  keys  on  the  keyboard  shall  move  the  text  one 
increment  (i.e.,  one  line  or  one  character)  in  the  specified  direction. 

7.  In  a  multi-lined  text  field,  <Ctrl>  in  combination  with  the  arrow  keys  shall  move  one 
large  increment  (i.e.,  one  word  or  one  paragraph)  in  the  specified  direction. 

8.  In  a  multi-lined  text  field,  <Home>  and  <End>  shall  move  the  text  cursor  to  the 
beginning  and  end  of  a  line. 

9.  In  a  multi-lined  text  field,  <Ctrl>  +  <Home>  and  <Ctrl>  +  <End>  shall  move  the  text 
cursor  to  the  beginning  and  end  of  the  text  file. 

10.  If  multi-line  text  is  in  a  window  with  a  default  action,  <Enter>  or  <Ctrl>  +  <Retum>  shall 
execute  the  default  action. 

11.  In  a  multi-lined  text  field,  <Retum>  shall  insert  a  carriage  return. 

12.  In  a  single-lined  text  field,  the  arrow  keys  on  the  keyboard  shall  navigate  to  a  different 
component. 

13.  In  a  single-lined  text  field,  <Ctrl>  in  combination  with  the  arrow  keys  shall  move  one 
large  increment  (i.e.,  one  word  or  one  paragraph)  in  the  specified  direction. 

14.  Users  shall  be  provided  the  capability  to  back  up  to  any  text  field  and  edit  the  entry  prior 
to  entering  data  into  the  system. 

15.  Selecting  a  text  field  with  the  pointer  shall  make  that  the  focused  or  active  field  and  place 
the  cursor  at  the  beginning  of  the  text  field.  The  entire  field  may  be  selected  upon  initial 
entry  if  desired  by  the  designer. 

16.  A  displayed  pointer  shall  be  positioned  by  the  system  at  the  first  data  entry  field  when  the 
form  is  displayed.  The  cursor  shall  be  advanced  by  a  tab  key  to  the  next  data  entry  field 
when  the  user  has  completed  entry  of  the  current  field  or  shall  automatically  move  to  the 
next  field  when  the  end  of  the  field  is  reached.  The  default  value  for  the  automatic 
movement  of  the  cursor  shall  be  off. 


Source 

CSFAB,  TBM,  MS1472F. 
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Discussion 


G2.  Automatic  tabbing  shall  be  restricted  to  situations  where  data  entry  occurs  in  fixed-length 
entries.  Developers  shall  not  combine  auto  tabbed  and  manually  tabbed  fields  in  the  same  data 
entry  window. 

G3.  This  occurs  only  if  the  text  field  is  empty.  If  there  is  existing  data  in  the  field,  then  the 
pointer  tabs  to  its  previous  location  the  last  time  the  field  was  active. 

17.2.4  Manipulation 

1.  Users  shall  be  provided  the  capability  to  easily  specify  the  format  of  a  document  and  the 
font  type,  size,  and  style. 

2.  Automatic  line  break  and  word-wrap  at  the  right  margin  shall  be  available. 

3.  Automatic  pagination  (page  numbers  based  on  the  number  entered  by  users)  shall  be 
available. 

4.  The  window  shall  be  formatted  as  the  printed  output,  or  an  option  to  see  this  format  shall 
be  provided. 

5.  A  copy  of  the  original  document  shall  be  retained  until  users  confirm  that  it  is  to  be 
changed. 

6.  The  original  document  shall  not  be  modified  automatically  as  users  make  each  editing 
change. 

7.  Applications  shall  provide  both  Find  and  Find  and  Replace  capabilities  for  users.  The 
Find  and  Find  and  Replace  capability  shall  be  in  accordance  with  the  design  guidance  in 
MSWUE  styles.  In  a  Find  capability,  users  shall  type  the  text  string  (case-sensitivity  shall 
be  optional)  and  the  first  instance  is  highlighted.  In  the  Find  and  Replace  capability,  users 
shall  type  the  text  string  and  the  first  instance  is  highlighted  or  if  requested  a  global 
replace-all  capability  shall  make  all  the  changes  requested. 

8.  Where  text  formats  are  a  user  option,  a  convenient  means  shall  be  provided  to  allow  the 
user  to  specify  and  store  for  future  use  the  formats  that  have  been  generated  for  particular 
applications. 


Source 

TBM,  MS1472F 

17.3  Data  display 

17.3.1  Data  display  characteristics 

1 .  Multi-coloured  text  shall  not  be  used  as  a  code  to  sort  data. 
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2.  Multiple  colour-codes  shall  not  be  used  unless  the  colours  are  already  associated  with 
specific  meanings. 

3.  Every  third  or  fifth  row  of  data  shall  be  separated  by  a  delimiter.  The  delimiter  may 
include  light  background  shading  in  groups  of  three  to  five  rows  (similar  to  old-fashioned 
computer  paper),  separator  lines,  or  other  means  consistent  with  the  application. 

4.  Information  shall  be  automatically  justified. 

5.  Justification  rules  shall  be  followed:  left-justify  alphabetic  data;  right-justify  integers; 
justify  decimal  data  on  the  decimal  point. 

6.  When  five  or  more  alphanumeric  characters  without  natural  organization  are  displayed, 
the  characters  shall  be  grouped  in  blocks  of  three  to  five  characters  within  each  group 
separated  by  a  minimum  of  one  blank  space  or  other  separating  character  such  as  a 
hyphen  or  slash. 

7.  Descriptive  wording  shall  be  employed  when  labelling  data  fields;  use  of  arbitrary  codes 
shall  be  avoided. 

8.  The  ordering  and  layout  of  corresponding  fields  shall  be  consistent  and  have  the  same 
names. 

9.  Users  shall  not  be  required  to  translate  feedback  messages  by  use  of  reference  system  or 
code  sheets.  Abbreviations  shall  be  avoided. 

10.  Only  data  essential  to  the  user's  needs  shall  be  displayed. 

1 1 .  Data  presented  to  the  user  shall  be  in  a  readily  usable  and  readable  form  such  that  the  user 
does  not  have  to  transpose,  compute,  interpolate  or  mentally  translate  into  other  units, 
number  bases,  or  languages. 

12.  A  text  window  shall  be  wide  enough  to  display  an  entire  line  of  text  without  scrolling. 
Text  windows  shall  be  no  wider  than  40-60  characters. 

13.  Text  fields  that  represent  real  data  shall  be  distinguishable  from  text  fields  that  represent 
test  or  simulated  data. 

14.  If  a  specific  format  is  required,  an  example  of  that  format  or  an  example  entry  shall  be 
displayed. 

15.  Text  fields  that  require  certain  text  formatting  shall  provide  this  formatting  automatically 
(e.g.,  convert  small  case  to  CAPS  where  required). 

16.  The  operator  shall  be  given  visual  cues  for  unacceptable  entries,  required  entries,  and  the 
location  of  the  present  entry  field. 

17.  Once  an  entry  has  been  made,  the  operator  shall  not  have  to  re-enter  this  information  but 
rather  it  shall  be  selectable  (e.g.,  once  the  operator  enters  a  name  the  name  can  be 
selected  from  an  option  menu  or  list  box). 


DRDC  Toronto  TR  2009-062 


167 


18.  A  name  entered  into  an  option  menu  or  list  box  shall  be  able  to  be  deleted  at  the  request 
of  the  user. 

19.  Operators  shall  not  have  to  memorize  codes  for  objects  with  commonly  known  names 
unless  the  code  is  also  commonly  known  by  both  novice  and  experienced  users  (e.g.,  do 
not  have  a  code  for  selecting  a  certain  missile,  instead  use  that  missile's  name  and  have 
the  system  provide  the  required  codes). 

20.  The  user  shall  not  have  to  rely  on  memory  to  interpret  new  data;  each  data  display  shall 
provide  needed  context,  including  recapitulating  prior  data  from  prior  displays  as 
necessary. 

2 1 .  The  user  shall  not  be  required  to  leam  mnemonics,  codes,  special  or  long  sequences,  or 
special  instructions. 


Source 

CSFAB,  TBM,  MS1472F,  UCA. 

Discussion 

Gl.  CSFAB  states  that  multi-coloured  text  shall  be  used  when  it  provides  additional  meaning 
that  can  not  be  achieved  by  sorting;  however,  multi-coloured  text  is  difficult  to  read  and  should 
not  be  used.  Colour  coding  can  instead  be  achieved  by  coloured  backgrounds,  or  familiar  colour 
codes  placed  next  to  the  items  to  be  grouped. 

17.3.2  Organization 

1 .  Data  fields  shall  be  organized  by  sequence  of  use,  frequency  of  use,  or  importance. 

2.  Displayed  data  items  that  are  critical  or  require  immediate  user  response  shall  be  grouped 
at  the  top  of  the  display. 

3.  Sets  of  data  that  are  associated  with  specific  questions  or  related  to  particular  functions 
shall  be  grouped  together  to  signify  those  functional  relationships. 

4.  Data  items  used  more  frequently  than  others  may  be  grouped  at  the  top  of  the  display. 

5.  Data  fields  shall  be  organized  with  related  fields  together  and  unrelated  fields  separated. 

6.  Data  fields  to  be  compared  on  a  character-by-character  basis  shall  be  positioned  one 
above  the  other  with  alignment  of  characters  to  be  compared. 

7.  Users  shall  be  able  to  obtain  information  about  a  data  field  and  its  contents. 

8.  Data  field  names  shall  be  unique;  the  same  names  shall  be  applied  throughout  the 
application. 

9.  Required  data  entry  text  fields  shall  be  distinguishable  from  optional  data  entry  text 
fields. 
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10.  Data  fields  with  values  that  cannot  be  changed  shall  be  displayed  in  a  read-only 
information  area. 

1 1 .  Location  of  recurring  data  shall  be  similar  among  all  data  displayed  and  common 
throughout  the  system. 

12.  Long  strings  of  numbers  shall  be  delimited  with  spaces,  commas,  or  slashes  (not  leading 
zeros). 

13.  Strings  of  alphanumerics  shall  be  grouped  into  sets  of  three  to  five  characters  or  grouped 
at  natural  breaks.  When  a  code  consists  of  both  letters  and  digits,  common  character  types 
shall  be  grouped  by  common  character  type  for  ease  of  location. 

14.  If  a  data  record  extends  beyond  a  line  and  the  entire  line  of  data  must  be  displayed  at  all 
times,  each  line  beyond  the  first  line  shall  be  identified  as  a  continuation  of  the  record. 

15.  If  a  data  record  extends  beyond  a  line  and  the  entire  line  of  data  does  not  need  to  be 
displayed  at  all  times,  a  method  shall  be  designed  so  that  users  can  select  an  individual 
data  record  and  view  all  the  data  fields  available  for  that  record. 

16.  Information  shall  be  presented  (or  requested)  only  to  an  operationally  valid  level  of  detail 
(tactical  significance);  unnecessary  detail  shall  be  removed  from  the  display. 


Source 

TBM,  D1SA,  MS1472F,  UCA. 

Discussion 

G16.  This  item  was  added  as  a  result  of  the  review  of  the  COMDAT  TD. 

17.3.3  Text 

1 .  It  is  essential  for  successful  operations  that  text  displayed  to  the  operators  shall  be  legible 
and  readable  under  operational  lighting  conditions  and  at  over-the-shoulder  viewing 
distances. 

2.  Legibility  refers  to  the  identification  of  single  characters  and  is  a  function  of  letter  height, 
stroke  width,  height  to  width  ratio,  contrast  ratio,  and  polarity.  If  standard  fonts  are  used, 
character  height  is  the  most  important  factor  when  designing  so  that  the  characters  are 
legible.  Characters  shall  be  legible. 

3.  Readability  is  the  ability  to  recognize  groups  of  letters  or  words  that  have  contextual 
meaning.  If  the  letter,  word,  or  line  spacing  of  text  is  too  close,  user  will  have  trouble 
recognizing  words.  If  the  spacing  is  too  large,  reading  performance  will  slow.  The  text 
line  length  also  determines  the  speed  and  ease  of  reading.  Contextual  text  shall  be 
readable. 

4.  Normal,  dimmed,  and  highlighted  text  shall  appear  and  behave  as  indicated  in  MSWUE. 

5.  Black  shall  be  used  for  text  in  windows. 
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6.  Fully  saturated  blue  text  shall  not  be  used  as  it  is  difficult  to  perceive. 

7.  White  text  shall  not  be  used  on  black  backgrounds  as  irradiation  causes  characters  to 
spread  out  and  lose  sharpness. 

8.  Light  text  on  dark  backgrounds  may  require  slightly  less  stroke  width  than  dark  text  on 
light  backgrounds.  This  is  due  to  irradiation,  which  is  a  phenomenon  that  causes  white 
features  on  a  black  background  to  appear  to  spread  out.  Any  polarity  advantages  seem  to 
lean  toward  dark  text  on  light  backgrounds. 

9.  Either  the  characters  or  the  background  shall  produce  a  minimum  luminance  level  of 
35cd/nr  (10  foot-lamberts). 

10.  The  text  to  background  contrast  ratio  shall  be  a  minimum  of  1.5:1  for  disabled  text  and 
3:1  for  normal  text.  Contrast  ratios  of  7: 1  to  20: 1  or  more  are  preferred. 

1 1 .  Smaller  character  heights  and  stroke  widths  shall  be  designed  with  higher  contrast  ratios 
to  maintain  the  same  perceptibility  as  larger  letters.  For  example,  letters  of  10  minutes  of 
arc  would  need  a  contrast  ratio  of  19:1  to  provide  the  same  legibility  as  letters  of  20 
minutes  of  arc  with  a  3:1  (1.86:1)  contrast  ratio  (equivalent  contrast  ratio  formulas). 

12.  If  text  is  other  than  black,  the  text  colour  shall  have  sufficient  contrast  with  background 
to  be  readable. 

13.  Sans  serif  fonts  shall  be  used  for  all  text  displayed. 

14.  Use  a  font  equivalent  to  the  windows  appearance  of  MS"  San  Serif  or  Tahoma  for 
displaying  system  generated  text  in  sentence  format  and  labels. 

15.  The  title  bar  text  shall  use  the  bold  setting  equivalent  of  the  basic  system  font  chosen. 

16.  Except  for  title  bars,  bold  or  italic  fonts  shall  not  be  used  for  interface  text. 

17.  Bold  text  shall  be  used  in  menus  to  indicate  that  a  command  is  a  default  action. 

18.  The  text  in  each  window  shall  be  of  sufficient  size  to  be  legible  by  users  when  they  are  at 
an  over-the-shoulder  viewing  distance  from  the  screen. 

19.  The  minimum  font  size  shall  subtend  10  minutes  of  visual  arc  at  the  longest  viewing 
distance.  The  minimum  font  size  for  text  that  requires  rapid  readability  is  1 6  minutes  of 
visual  arc  with  a  preferred  size  of  20-22  minutes  of  visual  arc. 

20.  For  reading  lines  of  text,  the  maximum  font  shall  be  24  minutes  of  visual  arc.  Font 
heights  greater  than  24  minutes  of  visual  arc  shall  only  be  used  for  titles  or  labels 
consisting  of  single  words  or  short  phases. 

21.  Minimum,  preferred,  and  maximum  character  heights  at  a  minimal  over-the-shoulder 
viewing  distance  are  respectively  0.13,  0.16,  and  0.19  inches.  The  OMI  shall  be  designed 
for  the  minimum  over-the-shoulder  viewing  distance  (27  inches). 

22.  Text  character  height  shall  be  l/200th  of  the  viewing  distance. 
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23.  Text  character  width  shall  be  50-100  percent  of  character  height. 

24.  The  text  character  stroke  width  minimum  shall  be  10-12.5  percent  of  character  height. 

25.  Spacing  requires  one  stroke  width  minimum  between  all  characters  and  a  maximum 
spacing  of  one  average  character  width.  Spacing  between  words  requires  an  average 
character  width.  Spacing  between  lines  shall  normally  be  the  height  of  an  uppercase 
character  but  may  be  reduced  to  the  height  of  a  lowercase  letter  if  space  is  at  a  premium. 

26.  Text  characters  shall  contain  a  minimum  7X9  dot  matrix  construction. 

27.  Text  used  for  briefing  presentations  shall  use  at  minimum  a  10  X  14  dot  matrix  format, 
double  stroke  width. 

28.  Applications  with  word  processing  capabilities  shall  provide  a  choice  of  fonts  as  a  user- 
selectable  option. 

29.  The  character  stroke  width  of  a  system  font  shall  be  at  least  2  pixels  in  thickness. 

30.  The  selected  font  style  shall  be  legible  in  various  display  resolutions  from  72  pixels  per 
inch  to  120  pixels  per  inch. 

31.  User  font  cells  shall  be  the  same  height  as  the  system  fonts  that  will  be  used  with  them. 
The  glyphs  within  the  character  cell  for  a  user  font  shall  be  positioned  at  the  same 
location  and  have  the  same  height  as  those  for  the  associated  system  fonts. 

32.  Fixed  width  fonts  shall  be  used  for  text  field  widgets  receiving  data  entry  and  for  system 
generated  non-editable  text  fields. 

33.  Consistent  grammatical  structure  shall  be  used  for  all  non-editable  text  in  windows. 

34.  Wording  shall  be  consistent  and  use  familiar  terms  and  task-oriented  language  of  users. 

35.  Blocks  of  text  shall  be  broken  into  smaller,  meaningful  groups. 

36.  Continuous  text  shall  be  phrased  in  simple  sentences,  in  the  affirmative,  and  in  active 
voice. 

37.  A  sequence  of  events  or  steps  shall  be  presented  in  the  order  the  steps  are  performed. 

38.  The  referent  for  it  or  they  in  a  sentence  shall  be  easily  identified. 

39.  Normal  punctuation  rules  shall  be  followed,  and  contractions  and  hyphenation  shall  be 
avoided. 

40.  Editable  text  shall  be  displayed  in  upper/lowercase  as  appropriate  to  the  task  being 
performed. 

41.  Stored  text  shall  be  shown  in  standard  format;  text  editing  is  converted  into  the  standard 
format. 


DRDC  Toronto  TR  2009-062 


171 


42.  All  labels,  text,  titles,  acronyms,  words  and  headings  shall  be  spelled  correctly. 

43.  All  terms  shall  be  used  consistently  throughout  the  OMI.  Examples  include  underlying 
definitions  such  as  “best  quality”  from  different  sensors  for  local  and  fused  data,  terms 
such  as  “Platform”,  and  actions  such  as  “clear  alarms”. 


Source 

CSFAB,  TBM,  D1SA,  MS1472F,  MSWUE,  UCA. 

Discussion 

Two  lighting  conditions  are  used  in  the  Halifax-class  control  room.  These  lighting  conditions  are 
the  following: 

•  Normal  operations  room  lighting  (dim  lighting) 

•  Dark  adaptation  conditions  (red  lighting) 

The  provisions  for  text  size  and  contrast  in  this  section  were  developed  for  operations  under 
normal  office  lighting.  Because  visual  acuity  is  reduced  under  sub-optimal  room  lighting,  the 
provisions  are  under-specified  for  use  in  the  Halifax-class  control  room.  These  provisions  may 
require  adjustment  and  should  be  considered  to  be  minimum  starting  points  for  design.  To  ensure 
that  the  text  is  appropriate  at  the  over-the-shoulder  viewing  distance,  and  appropriate  under  the 
ambient  lighting  conditions,  all  of  the  design  solutions  should  be  validated  and  tested  under  the 
expected  operational  conditions. 

G12.  Nearly  all  text  is  black  with  the  exception  of  white  (or  off-white)  letters  on  very  dark 
backgrounds. 

G18.  The  CSFAB  requirement  is  that  the  text  shall  be  legible  at  a  normal  viewing  distance. 
This  Guide  requires  that  the  text  be  legible  at  the  minimum  over-the-shoulder  viewing  distance 
(i.e.,  27  inches).  This  more  conservative  specification  benefits  both  over-the-shoulder  viewing 
and  the  seated  operator. 

G19.  The  calculation  of  visual  angle,  in  minutes  of  arc,  for  a  given  character  size  (height  or 
width)  is: 


Visual  angle  =  60  *  arctan(  size  /  distance) 

where  the  units  for  size  of  the  character  and  distance  from  the  screen  to  the  user  are  the  same. 

G21.  The  calculation  of  character  height  for  a  given  visual  angle,  in  minutes  of  arc,  is: 

Size  =  tan(minutes  of  arc/60)  *  distance 

where  the  units  for  size  of  the  character  and  distance  from  the  screen  to  the  user  are  the  same. 

G22.  For  example,  a  viewing  distance  of  36  inches  requires  a  .  1 8  inch  character  height. 

G42.  This  guideline  and  the  next  one  were  added  as  a  result  of  the  review  of  the  COMDAT 

TD. 
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17.3.4  Labels 


1.  Colons  shall  be  included  when  static  text  is  used  to  label  another  control. 

2.  The  baselines  of  text  labels  shall  be  aligned  with  the  baselines  of  the  text  boxes. 

3.  The  presence  and  location  of  control  input  data  entered  by  the  user  shall  be  clearly  and 
appropriately  indicated.  Data  displayed  shall  not  mislead  the  user  with  regard  to 
nomenclature,  units  of  measure,  sequence  of  task  steps,  or  time  phasing. 

4.  The  label  shall  be  followed  by  a  colon  and  two  spaces  before  the  text  (Label: 
[space]  [space]text). 

5.  If  a  label  pertains  to  a  group  of  text,  this  group  of  text  shall  be  offset  from  the  rest  of  the 
text  by  an  outline  or  spacing.  If  an  outline  box,  or  separator  line,  is  used,  the  label  shall  be 
integral  with  the  outline  box  or  separator  line. 

6.  Labels  shall  be  simple,  concise  words  or  phrases  in  terms  familiar  to  the  operator. 

7.  Labels  for  push  buttons,  pull-down  menu  selection,  or  any  other  items  that  perform  an 
action  shall  be  verbs.  Labels  for  radio  buttons,  checkboxes,  lists  or  any  items  that  present 
options  shall  be  nouns.  Labels  for  groups  of  components  shall  be  nouns.  See  MSWUE  for 
examples  of  noun/verb  and  label  combinations. 

8.  If  a  unit  of  measurement  is  always  used,  it  shall  be  part  of  the  label  and  does  not  have  to 
be  entered. 

9.  If  text  field  labels  appear  to  the  left  of  their  text  fields,  text  field  labels  shall  use  a  colon 
(:)  to  separate  the  label  from  the  text  field. 

10.  The  label  for  a  text  field  shall  not  display  a  shadow. 

11.  Text  labels  of  more  than  one  word  shall  not  be  run  together,  nor  shall  they  be  separated 
by  an  underscore,  or  any  delimiters  other  than  a  single  space. 

12.  Required  data  entry  text  fields  shall  be  distinguishable  from  optional  data  entry  text 
fields.  A  colour-coded  one-pixel  border  may  be  placed  around  a  text  field.  By  limiting  the 
border  resource  to  one  pixel,  it  will  not  interfere  with  the  highlight  border.  The  presence 
or  absence  of  the  border  may  be  used  to  distinguish  required  or  optional  data. 

13.  A  text  field  label  shall  appear  to  the  left  or  above  the  text  field  and  describes  what  is  to  be 
entered  or  what  is  to  be  displayed. 

14.  A  text  field  label  of  a  text  field  shall  include  cues  regarding  expected  format  of  the  entry. 

15.  Text  field  labels  shall  have  the  same  background  colour  as  the  window  on  which  they 
appear. 

16.  Labels  shall  be  consistently  located  adjacent  to  (and  preferably  above  or  to  the  left  of)  the 
data  group  or  message  they  describe. 
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17.  Labels  shall  be  unambiguously  related  to  the  group,  field,  or  message  they  describe. 

18.  Labels  shall  be  visually  distinct  from  other  text  and  the  accentuating  technique  shall  be 
different  and  easily  distinguished  from  the  method  used  to  highlight  or  code  emergency 
or  critical  messages. 

19.  Labels  shall  be  unique  and  meaningful  to  distinguish  them  from  data,  error  messages,  or 
other  alphanumerics. 

20.  Each  text  field,  editable  or  non-editable,  shall  have  a  label  located  to  the  top  or  left  of  the 
field. 

2 1 .  When  data-entry  fields  are  very  long  the  label  may  be  placed  above  the  left  edge  of  the 
field. 


Source 

CSFAB,  TBM,  D1SA,  MS1472F,  MSWUE,  Handbook  5. 

17.3.5  Justification 

1 .  All  standard  text  and  columns  of  text  shall  be  left  justified.  All  lines  of  text  shall  be 
wrapped  to  fit  in  the  provided  text  window  even  if  this  window  is  resized.  This  eliminates 
the  need  for  the  operator  to  horizontal-scroll  through  text. 

2.  Tabular  data  and  tables  shall  not  be  wrapped.  Vertical  scrolling  shall  be  used  to  access 
text  not  displayed  in  the  text  window. 

3.  An  automatic  word  wrap  (carriage  return)  shall  be  provided  when  the  text  reaches  the 
right  margin  for  entry/editing  of  unformatted  text.  User  override  shall  be  provided. 

4.  Numeric  data  without  decimals  shall  be  right  justified.  Numeric  data  with  decimals  shall 
be  justified  on  the  decimal  point. 

5.  Fabels  in  columns  shall  be  left  justified  with  the  associated  alphanumeric  text  being  left 
justified  after  the  longest  label.  Fabels  shall  be  positioned  to  read  left  to  right  and/or  top 
to  bottom.  Fabels  shall  be  of  approximately  equal  length  to  facilitate  associating  the  label 
with  the  text  field. 


Source 

CSFAB,  MS1472F. 

17.3.6  Leading  zeroes 

1 .  Feading  zeros  shall  not  be  displayed  unless  required  for  clarity.  However,  leading  zeros 
may  be  displayed  during  data  input  to  ensure  the  user  did  not  accidentally  leave  out  a 
digit. 

2.  Feading  zeros  shall  be  displayed  for  headings,  bearings,  and  other  compass  references 
normally  displayed  in  three  digit  groups. 
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Source 


CSFAB,  UCA. 

17.3.7  Numbers 

1.  When  displaying  numbers  the  number  zero  shall  have  a  slash  through  it  so  it  is  not 
confused  with  a  capital  "O".  The  letter  L  and  the  digit  1  shall  also  be  displayed  so  as  not 
to  be  contused  with  each  other. 

2.  Error  checking  shall  be  provided  so  that  letters  are  not  permitted  in  fields  specifically 
designated  for  numbers  and  vice  versa. 

3.  If  numbers  are  rounded  or  estimated,  the  rounding  shall  be  done  by  the  system  and 
visually  displayed  for  the  operator  to  see. 

4.  Numbers  shall  only  be  rounded  to  the  level  of  tactical  significance. 

5.  Any  computations  using  rounded  or  estimated  numbers  shall  display  the  answer  in  the 
appropriate  number  of  significant  digits. 

6.  Numbers  in  columns  shall  be  justified  on  the  virtual  or  actual  decimal. 

7.  Graphic  presentation  aids  interpretation.  When  graphic  presentation  of  numbers 
positively  impacts  operational  effectiveness,  numbers  shall  be  presented  graphically. 

8.  For  small  numbers  the  graphic  shall  be  a  one-to-one  representation  of  the  numbers. 

9.  For  large  numbers,  the  graphic  shall  be  a  summary  of  the  relevant  information. 

10.  Values  of  zero  shall  not  be  left  blank  but  shall  instead  be  presented  as  zeros.  Missing  or 
unknown  values  shall  not  be  left  blank  but  instead  shall  be  displayed  with  place  markers 
such  as  periods  or  dashes. 


Source 

CSFAB,  MSWUE,  UCA. 

Discussion 

The  last  two  guidelines  were  added  as  a  result  of  the  review  of  the  COMDAT  TD. 

G8.  For  example,  since  the  Flalifax-Class  carries  a  maximum  of  eight  Sea  Sparrow  missiles, 
the  number  of  missiles  remaining  and  fired  can  be  presented  as  individual  symbols  (such  as  icons 
or  geometric  shapes)  depicting  each  missile  and  missing  missile.  The  number  should  also  be 
presented  in  numerals  so  that  the  operators  do  not  have  to  count. 

G9.  A  progress  bar  showing  the  time  remaining  is  an  excellent  example.  The  progress  bar 
gives  at-a-glance  information  as  to  how  far  along  the  process  is  (in  the  example  of  ammunition,  it 
would  give  a  rough  idea  of  how  much  ammunition  is  used  and  remaining).  The  graphics  shall  be 
supported  with  specific  numbers  so  that  the  operator  can  report  the  precise  values  as  required. 
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17.3.8  Units  of  measurement 


1.  If  the  field  is  associated  with  a  standard  and  consistent  dimension  (e.g.,  feet)  then  this 
dimension  shall  be  provided  by  the  system  and  listed  to  the  right  of  the  field. 

2.  If  a  finite  number  of  dimensions  are  associated  with  the  field  then  the  possible 
dimensions,  as  an  option  menu,  shall  be  provided  and  presented  to  the  right  of  the  field. 

3.  If  a  multitude  of  dimensions  are  possible,  use  another  text  field  (or  a  menu)  for  the  input 
of  the  dimension. 

4.  Any  text  that  requires  a  unit  of  measure  shall  be  immediately  followed  by  either  the 
proper  unit  of  measure  or  a  control  to  select  a  unit  of  measure. 

5.  The  system  shall  allow  users  to  input  data  in  a  familiar  unit  of  measure. 

6.  The  units  of  displayed  data  shall  be  consistently  included  in  the  displayed  labels. 


176 


DRDC  Toronto  TR  2009-062 


Source 


CSFAB,  MS1472F. 

17.3.9  Capitalization 

1 .  Titles  and  major  headings  shall  be  presented  in  book  title  case. 

2.  Use  of  all  uppercase  letters  shall  be  reserved  for  acronyms  and  security  classification 
banners. 

3.  Arabic  rather  than  Roman  numerals  shall  be  used  when  information  has  to  be  numbered. 

4.  When  numeric  data  is  displayed  or  required  for  control  input,  such  data  shall  be  in  the 
decimal,  rather  than  binary,  octal,  hexadecimal  or  other  number  system. 

5.  All  sentences  and  lines  of  text  shall  be  presented  in  a  combination  of  upper  and  lower¬ 
case  letters,  following  standard  capitalization  rules.  Mixed  case  type  is  recommended  as 
it  results  in  faster  word  recognition,  especially  in  sentences. 

6.  Any  displayed  message  or  datum  selected  as  an  option  or  input  to  the  system  shall  be 
highlighted  to  indicate  acknowledgment  by  the  system. 


Source 

CSFAB,  TBM,  MS1472F. 

17.3.10  Acronyms  and  abbreviations 

1 .  An  acronym  in  an  application  shall  be  used  to  denote  only  one  meaning.  Acronyms  shall 
not  be  created  when  existing  acronyms  are  already  defined. 

2.  Acronyms  and  abbreviations  shall  be  used  only  if  shorter  than  the  full  name  and  only  if 
understood  by  users. 

3.  Abbreviations  shall  be  the  shortest  possible  length  that  will  ensure  uniqueness. 

4.  Abbreviations  shall  be  meaningful,  recognizable,  and  used  consistently. 

5.  Words  not  commonly  abbreviated  by  the  operators  shall  not  be  abbreviated. 

6.  A  dictionary  shall  be  available  (e.g.,  in  Help)  for  decoding  abbreviations  and  acronyms. 

Source 

CSFAB,  TBM,  MS1472F. 

17.3.11  Tables 

1 .  Tabular  data  windows  shall  be  used  for  information  display  only. 
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2.  Where  items  in  a  list  are  displayed  in  multiple  columns,  the  items  shall  be  ordered 
vertically  within  each  column. 

3.  Each  column  shall  have  a  heading  and  be  clearly  separated  from  other  columns  by  spaces 
(minimum  of  4  spaces)  and/or  lines. 

4.  Tables  shall  provide  sorting  on  all  sortable  columns  through  the  column  heading. 

5.  When  selected,  the  sorting  control  on  the  heading  shall  indicate  the  column  that  was 
sorted  and  the  direction  in  which  it  is  sorted. 

6.  If  multiple  sorts  are  required  use  check  boxes  in  a  table;  a  non-editable  field  shall  be 
provided  to  display  the  order  of  the  sort  criteria.  Column  labels  shall  be  placed  in  the  non- 
editable  field  in  the  order  in  which  the  column  label  check  boxes  or  push  buttons  were 
chosen.  When  a  column  label  check  box  or  push  button  is  de-selected,  the  label  shall  be 
removed  from  the  sort-order  field. 

7.  Where  items  in  a  list  are  displayed  in  multiple  columns  then  selecting  an  individual  item 
in  one  column  shall  also  select  the  data  in  the  corresponding  line  of  all  the  columns. 

8.  If  there  are  multiple  pages  in  a  table,  the  row  and  column  labels  shall  remain  visible  along 
the  edges  of  the  page. 

9.  The  widths  of  columns  containing  the  same  data  elements  shall  be  uniform  and  consistent 
within  a  table  and  from  one  table  to  another. 

10.  Tabular  displays  shall  not  extend  over  more  than  one  page  horizontally. 

11.  Tables  shall  be  scrollable  by  means  of  one  scroll  bar  that  is  located  on  the  right  side  of 
the  right-most  column. 

12.  The  width  of  each  column  shall  at  a  minimum  be  the  same  width  as  the  column  label. 

13.  If  the  width  of  the  longest  data  element  in  a  list  is  unknown  or  is  variable,  horizontal 
scroll  bars  shall  be  used  for  individual  columned  lists.  However,  horizontal  scroll  bars 
shall  only  be  displayed  when  needed. 

14.  Column  labels  shall  be  identical  for  all  pages;  the  last  line  on  a  page  is  the  first  line  on  the 
next  page. 

15.  Tables  shall  be  arranged  to  show  similarities,  differences,  trends,  or  relationships. 
Depending  on  the  task,  data  may  be  arranged  in  sequential,  spatial,  alphabetical, 
functional  and/or  chronological  order. 

16.  Data  that  are  important,  require  immediate  response,  and/or  are  frequently  used,  shall 
appear  at  the  top  of  the  table. 

17.  Rows  and  columns  shall  be  labelled  distinctively. 
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18.  Tabular  data  shall  be  displayed  in  rows  and  columns.  If  the  data  in  the  rows  have  an 
order,  the  order  shall  increase  from  left  to  right.  If  the  data  in  the  columns  have  an  order, 
the  order  shall  increase  from  top  to  bottom. 

19.  Tabular  data  displays  shall  be  used  to  present  row-column  data  to  aid  detailed  comparison 
of  ordered  sets  of  data. 

20.  Tables  or  other  displays  that  contain  similar  data  shall  be  easily  visually  distinguished  by 
the  operators. 

Source 

CSFAB,  TBM,  MS1472F,  MSWUE,  UCA. 

17.3.12  Multiple  pages 

1 .  If  possible,  related  data  fields  shall  appear  on  the  same  page. 

2.  When  a  display  contains  too  much  data  for  presentation  in  a  single  frame,  the  data  shall 
be  partitioned  into  separately  displayable  pages. 

3.  If  there  are  multiple  pages,  each  page  shall  have  the  same  title,  current  page,  and  total 
pages  indicator. 

4.  When  partitioning  displays  into  multiple  pages,  functionally  related  data  items  shall  be 
displayed  together  on  one  page. 

5.  The  numbering  of  items  shall  be  continuous  from  one  page  to  the  next.  For  example,  if 
the  last  numbered  item  on  page  1  is  8  then  the  first  numbered  item  on  page  2  is  9. 

6.  If  a  data  window  has  more  than  one  page,  the  window  includes  paging  controls. 

Source 

TBM,  MS1472F. 

17.3.13  Data  query 

1.  The  data  query  language  provided  to  the  users  shall  reflect  the  structure  of  the  data  as 
perceived  by  the  users. 

2.  The  language  shall  allow  the  users  to  specify  the  data  to  retrieve  then  display  and 
manipulate  it. 

3.  Users  shall  be  provided  the  capability  to  request  data  without  having  to  tell  the  system 
how  to  find  it. 

4.  Queries  shall  use  operationally  meaningful  terminology  that  does  not  reflect  how  the  data 
are  stored. 
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5.  Users  may  construct  simple  and  complex  queries,  create  predefined  queries,  and  save, 
retrieve,  and  execute  these  queries. 

6.  The  language  shall  permit  alternate  forms  of  the  same  query  using  natural  language. 

7.  Users  shall  be  prompted  to  confirm  a  query  if  data  retrieval  time  will  be  excessive. 

Source 

TBM,  D1SA. 

17.4  Data  validation  and  error  checking 

1 .  A  validity  check  shall  be  done  on  data  entered,  with  visual  error  messages. 

2.  Syntactic  error  checking  shall  occur  immediately  upon  leaving  a  data  entry  field. 

3.  Users  shall  be  notified  of  syntactic  errors  in  a  standard  message  area  or  error  message 
window. 

4.  Semantic  error  checking  shall  occur  as  soon  as  is  possible.  If  semantic  error  checking 
occurs  upon  leaving  a  field,  users  shall  be  informed  of  the  error  and  be  provided  the 
capability  to  revert  the  collection  of  data  entry  fields  (form,  database  record,  etc.)  to  its 
previous  state.  If  semantic  error  checking  occurs  when  an  entire  form  or  record  is 
submitted  as  a  collection,  the  user  shall  be  provided  with  the  capability  to  correct  the 
individual  fields  in  error  before  again  submitting  the  collection  of  data  entry  fields.  Due 
to  the  increased  potential  for  user  error  with  field-by-field  data  entry,  it  is  recommended 
that  data  entry  and  semantic  error  checking  be  accomplished  on  a  record-by-record  basis. 

5.  Data  entries  shall  be  validated  by  the  system  for  correct  format,  legal  value,  or  range  of 
values.  Where  repetitive  entry  of  data  sets  is  required,  data  validation  for  each  set  shall  be 
completed  before  another  transaction  can  begin. 

6.  Users  shall  not  be  prevented  from  leaving  a  field  with  an  error  with  it.  Rather,  they  shall 
be  allowed  to  fix  the  error  at  their  own  pace. 

7.  When  required  data  entries  have  not  been  entered,  the  omission  shall  be  indicated  to  the 
user  and  either  immediate  or  delayed  input  of  the  missing  items  shall  be  allowed.  Delayed 
entry  shall  be  avoided;  however,  if  it  is  necessary,  the  user  shall  be  required  to  designate 
the  field  to  indicate  that  the  missing  item  is  delayed,  not  overlooked. 
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Source 


TBM,  MS1472F. 

Discussion 

Syntactic  error  checking  is  done  to  be  sure  that  data  are  entered  in  the  correct  format.  This 
includes  that  the  correct  numeric  data  falls  within  minimum  and  maximum  range  requirements 
and  that  alphanumeric  data  is  recognizable  by  the  system.  Alphanumeric  data  may  include 
abbreviations  and  acronyms  that  must  be  in  the  proper  format. 

Semantic  error  checking  is  done  to  ensure  that  the  meaning  or  context  of  information  entered  is 
correct.  This  means  that  one  data  entry  field  must  be  compared  against  another  field.  For 
example,  an  error  should  result  if  a  crew  has  been  assigned  to  a  non-existent  aircraft  tail  number. 
Detecting  this  type  of  error  requires  semantic  error  checking. 

Gl.  The  requirement  has  been  edited  to  remove  the  option  for  auditory  error  messages 
because  auditory  error  messages  are  disruptive  and  are  not  conducive  to  the  operations  room 
environment.  Note  that  this  guideline  does  not  address  operational  auditory  alerts  that  may  be 
appropriate. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  ease  of  use  and  design  consistency  of  all  data  display  and  entry  functions  in 
the  OMI. 

Operator  performance: 

•  Objective  assessment  of  use  and  usefulness  of  data  display  and  entry  functions. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  perceptions  of  usability  and  utility 
of  data  display  and  entry  functions  in  the  OMf  and  ESS. 
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18  Special  functions  and  formats 


18.1  Audible  alerts  and  flash  coding 

1 .  Audible  alerts  shall  be  avoided  unless  the  alarm  provides  an  alert  to  a  critical  situation, 
requiring  an  operator’s  response,  that  would  otherwise  be  missed,  and  that  the  operator 
would  not  be  otherwise  be  aware  (via  voice  or  radio  communication). 

2.  Non-critical  auditory  alarms  shall  not  be  implemented. 

3.  When  alarm  signals  are  established  based  on  user-defined  logic,  users  shall  be  permitted 
to  obtain  status  information  concerning  current  alarm  settings,  in  terms  of  dimensions 
(variables)  covered  and  values  (categories)  established  as  critical.  Alarm  status 
information  shall  be  provided  in  monitoring  situations  where  responsibility  may  be 
shifted  from  one  user  to  another  as  in  changes  of  shift. 

4.  Auditory  signals  shall  be  intermittent  in  nature  and  allow  sufficient  time  to  respond. 

5.  Auditory  signals  shall  be  distinctive  in  intensity  and  pitch  and  shall  not  exceed  two 
auditory  signals. 

6.  Audio  signals  used  in  conjunction  with  visual  displays  shall  be  supplementary  to  the 
visual  signals  and  shall  be  used  to  alert  and  direct  the  user's  attention  to  the  appropriate 
visual  display. 

7.  Flash  coding  is  used  only  to  display  urgent  information  for  user  attention.  Flashing 
symbols  shall  require  immediate  attention  that  supersedes  all  other  tasks. 

8.  Only  two  levels  of  flash  coding,  flashing  and  not  flashing,  shall  be  used.  Flashing 
symbols  shall  be  displayed  with  a  flash  rate  of  3-5  Hz  with  equal  duration  of  on  and  off 
cycles.  To  avoid  losing  the  object,  objects  shall  flash  between  two  intensity  levels,  bright 
and  dim  not  on  and  off. 

9.  A  maximum  of  5  symbols  shall  be  flashing  at  any  one  time. 

10.  The  operator  shall  be  provided  a  means  to  turn  the  flashing  off  and/or  the  flashing  shall 
only  last  for  a  specified  duration. 

1 1 .  A  flashing  symbol  may  be  used  for  flash  coding.  A  text  item  shall  not  be  flashed. 

12.  Users  shall  be  able  to  acknowledge  the  event  causing  the  flash  coding  and  suppress  the 
flash  if  desired. 


Source 

CSFAB,  TBM,  MS1472F. 

Discussion 
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Within  the  operational  context  an  excess  of  audible  alerts  is  known  to  contribute  to  information 
overload  and  negatively  impact  performance.  It  is  usual  for  operators  to  turn  off  all  audible 
alarms. 

G2.  The  requirement  was  edited  from  the  requirement,  “For  non-critical  auditory  alarms,  a 
simple  action  acknowledges/tums  off  the  signal.” 

G5.  Auditory  signals  tend  to  be  over-used  in  CCSs.  The  requirement  for  an  auditory  signal 
shall  be  considered  within  the  entire  operational  context  and  shall  be  used  rarely.  UCA  reduced 
the  number  of  auditory  signals  from  four  to  two  because  audible  codes  have  no  intrinsic  meaning 
to  the  operators. 

G8.  TBM  permit  two  levels  of  flash  rate;  the  second  level  is  defined  as  less  than  2  Hz  with 
equal  on/off  times. 

18.2  Date/time  and  latitude/longitude 

1.  All  dates  shall  be  presented  to  and  supplied  by  the  operator  in  the  DD  MMM  YY  (10 
MAY  68)  format.  The  characters  of  the  month  shall  be  capitalized.  The  spaces  between 
day  and  month  and  month  and  year  may  be  omitted.  If  the  day  or  year  is  a  single  digit  it 
must  be  preceded  by  a  zero.  The  notation  01JAN00  would  mean  January  1,  2000. 

2.  Time  shall  be  presented  to  and  supplied  by  the  operator  in  the  HH:MM:SSZ  (09:38:30Z) 
format.  HH  is  the  hour  in  a  24-hour  day,  MM  is  the  minute  with  a  leading  zero  if 
necessary,  and  SS  is  the  second  with  the  leading  zero  if  necessary.  Z  is  the  time  zone  with 
Zulu  time  as  the  default.  The  seconds  are  optional.  All  colons  are  required  and  the  Zulu 
(Z)  shall  be  capitalized. 

3.  The  display  shall  include  Zulu  time  and  local  time;  Zulu  time  shall  be  presented  above 
local  time. 

4.  The  date  time  group  shall  be  presented  on  the  status  bar  on  the  right-hand  edge. 

5.  If  the  operator  must  know  the  time  in  multiple  time  zones,  the  application  shall  provide  a 
separate  time  for  each  zone  or  provide  the  operator  the  ability  to  change  the  time  zone 
displayed. 

6.  A  date  time  group  shall  be  presented  to  and  supplied  by  the  operator  in  the  DD 
HH:MM:SSZ  MMM  YY  format  (seconds  are  optional)  where  DD  is  the  day  with  the 
leading  zero  if  necessary,  HH  is  the  hour  with  a  leading  zero  if  necessary,  MM  is  the 
minute  with  a  leading  zero  if  necessary,  SS  is  the  second  with  a  leading  zero  if  necessary, 
and  Z  is  the  time  zone  with  Zulu  as  the  default  with  MMM  as  the  abbreviated  month  and 
YY  is  the  last  two  digits  of  the  year.  All  colons  and  spaces  are  required. 

7.  Latitude  and  longitude  information  shall  be  displayed  in  separate  fields. 

8.  The  latitude  label  may  be  abbreviated  to  Lat.  Latitude  shall  be  presented  to  and  supplied 
by  the  operator  in  the  DD°MM'SS.T"  (09°06'30.3''N)  format.  A  two-digit  degree  and  the 
hemisphere  (N  or  S)  are  required.  Minutes,  seconds,  and  tenths  of  seconds  are  optional.  If 
provided,  minutes  and  seconds  each  must  contain  two  digits.  All  symbols  are  required  if 
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preceded  by  a  number  and  the  hemisphere  (N  or  S)  shall  be  capitalized.  A  hyphen  may  be 
substituted  for  the  degree  and  minute  symbols  DD-MM-SS.T  (09-06-30.3).  The  system 
should  know  in  which  hemisphere  it  is  located  and  use  this  as  the  default  value. 

9.  The  longitude  may  be  abbreviated  to  Long.  Longitude  shall  be  presented  to,  and  supplied 
by,  the  operator  in  the  DDD°MM'SS.T"  (090°06'30.3"E)  format.  DDD  is  the  degrees  of 
longitude,  MM  is  the  minutes  of  longitude  and  is  optional;  SS  is  the  seconds  of  longitude. 
A  three-digit  degree  and  the  hemisphere  (E  for  East  or  W  for  West)  are  required. 
Minutes,  seconds,  and  tenths  of  seconds  are  optional.  If  provided,  minutes  and  seconds 
must  each  contain  two  digits.  Seconds  of  longitude  are  only  presented  if  minutes  are 
presented.  All  symbols  are  required  if  preceded  by  a  number.  The  hemisphere  (E  or  W) 
shall  be  capitalized.  A  hyphen  may  be  substituted  for  the  degree  and  minute  symbols 
DDD-MM-SS.T  (090-06-30.3).  The  system  should  know  in  which  hemisphere  it  is 
located  and  use  this  as  the  default  value. 

10.  A  latitude/longitude  group  shall  be  presented  to  and  supplied  by  the  operator  in  the 
DD°MM'SS.T"  /  DDD°MM'SS.T"  (09°06'30.3"N  /090°06'30.3"E)  format.  All  symbols 
are  required  if  preceded  by  a  numeric  value.  Hyphens  may  replace  degree  and  minute 
symbols  and  the  second  symbol  may  be  omitted.  Latitude  shall  always  precede  longitude 
by  either  being  above  or  to  the  left  of  the  longitude  value.  Two  possible  latitude/longitude 
groupings  are  shown  below.  The  degrees  and  hemisphere  is  required  in  both  latitude  and 
longitude.  Minutes,  seconds,  and  tenths  are  optional  in  both  but  shall  follow  the  guidance 
described  in  this  document. 

«  Lat:  09°06'30.3"N 
Long:  090°06'30.3"E 

-  Lat/Long:  09°06'30.3"N  /  090°06'30.3"E 

Source 

CSFAB,  TBM,  D1SA,  UCA. 

Discussion 

Gl.  The  appropriate  format  for  the  date  information  depends  on  the  use  to  which  the 
information  will  be  put.  The  YYMMDD  format  does  not  disambiguate  the  month  and  day  fields 
across  international  conventions  and  thus  is  not  recommended.  The  DDMMYY  format  provides 
an  advantage  because  it  is  consistent  with  the  order  of  the  elements  in  the  preferred  Date  Time 
Group  format.  If  the  date  is  to  be  conveyed  to  other  entities  that  are  expecting  the  YYMMDD 
format  then  the  international  conventions  affect  the  display  of  choice.  If  the  operators  must  report 
or  otherwise  convey  the  two-digit  number  for  the  month,  then  support  for  the  conversion  shall  be 
provided. 

G2.  D1SA  and  TBM  call  for  a  similar  display,  but  without  the  colon  separators.  The  display  is 
easier  to  read  if  colons  are  used  to  separate  the  time  groups. 

G4.  Although  the  time  is  presented  in  the  lower  right  hand  comer  of  the  screen  in  Microsoft 
Windows;  the  upper  right  hand  comer  is  recommended  to  maintain  consistency  with  other  combat 
systems. 


184 


DRDC  Toronto  TR  2009-062 


G6.  DISA  and  TBM  call  for  a  similar  display,  without  the  colon  separators  or  space  between 
the  day  and  the  time. 

G8.  CSFAB  states  that  the  abbreviation  may  be  LAT  or  Lat.  Lat  is  the  preferred  abbreviation 
because  the  abbreviation  is  not  an  acronym. 

G9.  DISA  and  TBM  call  for  the  Hemisphere  to  be  placed  in  front  of  the  longitude  numbers  if 
thousands  of  minutes  are  displayed.  CSFAB  states  that  the  abbreviation  may  be  LONG  or  Long. 
Long  is  the  preferred  abbreviation  because  the  abbreviation  is  not  an  acronym. 

G10.  The  option  to  display  Latitude  and  Longitude  as  “Lat:  09°06'30.3"N  Long: 
090°06'30.3"E”  was  not  considered  because  it  is  more  difficult  to  extract  the  salient  information 
from  that  format. 


18.3  Graphical  schedules 

1.  A  graphical  schedule  displays  timelines  or  scheduled  events.  A  scheduled  event  shall  be 
represented  by  an  event  object  that  shall  be  a  line,  bar  or  other  object  whose  length  is 
proportional  to  the  amount  of  time  necessary  for  a  particular  task  or  task  element. 

2.  A  graphical  schedule  shall  be  presented  in  a  horizontal  format  and  shall  present  the 
schedule  tasks  or  resources  on  the  left  side  or  y-axis  of  a  graph.  Time  shall  be  presented 
along  the  x-axis.  Each  schedule  event  shall  be  displayed  by  an  object  to  the  right  of  its 
associated  task. 

3.  If  appropriate  to  the  application,  different  types  of  events  or  events  undertaken  shall  be 
differentiated  by  colour  coding,  shading,  or  short  alphanumeric  designations  on  or  above 
the  event  icons. 

4.  If  a  coding  scheme  is  applied  to  a  schedule,  users  shall  have  access  to  a  key  that  describes 
the  graphical  coding  technique  utilized.  It  is  recommended  that  no  more  than  nine 
differently  coded  event  icons  be  presented  on  a  schedule  at  one  time. 

5.  If  frequent  schedule  changes  are  anticipated,  users  shall  have  the  capability  to  reschedule 
an  event  object  by  directly  manipulating  the  event  object  by  means  of  the  pointing  device 
(e.g.,  dragging  and  dropping). 

6.  An  alternative  means  (other  than  dragging  and  dropping)  to  locate  an  event  object  on  a 
schedule  shall  also  be  supplied.  For  example,  one  alternative  is  to  support  direct  text 
entry  of  an  event  object  start  and  stop  times. 

7.  Users  shall  have  the  capability  to  select  a  schedule  start  and  stop  time  to  be  displayed  in  a 
graphical  schedule  window.  This  duration  time  can  be  a  superset  of  what  can  be 
displayed  in  the  window  at  one  time.  Users  shall  also  have  the  capability  to  display  all  or 
a  subset  of  the  pre-selected  duration  time.  For  example,  a  schedule  duration  may  display 
a  week;  however,  users  may  choose  to  display  one  or  more  days  out  of  the  pre-selected 
week. 

8.  If  graphical  schedules  are  overly  cluttered  or  require  a  high  level  of  precision,  grid  lines 
shall  be  used  to  correspond  with  individual  tasks  or  resources  and  times. 
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9.  If  required  by  the  application,  users  shall  have  the  capability  to  display  or  suppress  a 
gridline  that  indicates  the  present  date  and  time  on  the  schedule. 

10.  Users  shall  have  the  capability  to  select  an  individual  event  object  and  obtain  additional 
information  about  that  event. 

1 1 .  If  more  than  one  event  icon  is  used  per  task  or  resource,  then  a  label  shall  be  supplied  for 
each  event  icon  that  is  a  part  of  the  task  or  resource  being  scheduled.  For  example,  a 
schedule  may  display  planned  and  actual  times  or  earliest,  latest,  and  actual  times. 

12.  If  appropriate  for  an  application,  symbols  shall  be  combined  with  event  objects  to  display 
different  scheduling  attributes. 

Source 

TBM. 


18.4  List-to-list  transfer 


A  list-to-list  transfer  is  used  to  copy  (or  move)  items  from  a  source  list  (master  list)  to 
destination  list.  Figure  29  depicts  a  typical  convention  used  for  performing  this  type  of  action. 


Source 

list 


Available  Fields 


Exchange  SP  Level 
Exchange  Version 
OS  SP  Level 
OS  Version 
Server  name 
Site 
Status 
Users 


Direction 
of  move 


Add  A 


Ad' 


Destination 

list 


Selected  Fields 


<  Remove 
Remove  All 


Location 


Domain 


Figure  29:  Example  of  a  list-to-list  transfer. 


1 .  A  task  window  used  to  copy  items  from  a  source  list  (master  list)  to  a  destination  list  shall 
provide  one  Add  and  one  Remove  button.  If  many  items  are  in  a  list  an  Add  All  and/or  a 
Remove  All  button  may  also  be  included.  The  labels  Add  and  Remove  may  be  altered  to 
more  closely  fit  the  task  for  which  the  list-to-list  transfer  is  being  used. 

2.  List  to  list  transfers  shall  follow  the  Microsoft  Windows  conventions. 

3.  Vertically  arranged  push  buttons  shall  be  located  between  the  two  lists  and  shall  be  used 
to  invoke  the  functions  Add  All,  Add,  Remove,  and  Remove  All.  Add  All  shall  be  on  the 
top,  then  Add,  then  Remove,  and  Remove  All  on  the  bottom.  Selecting  one  or  multiple 
items  from  the  original  list  and  selecting  Add  shall  move  these  items  to  the  destination 
list.  Selecting  Add  All  shall  move  all  items  from  the  original  list  to  the  destination  list. 
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Selecting  one  or  multiple  items  from  the  destination  list  and  selecting  Remove  shall  move 
these  items  to  the  original  list.  Selecting  Remove  All  shall  move  all  items  from  the 
destination  list  to  the  original  list. 

4.  In  some  tasks  it  may  be  preferable  to  copy  instead  of  move  items  from  the  original  list  to 
the  destination  list.  Items  shall  then  be  marked  with  an  asterisk  to  show  they  have  already 
been  copied.  Multiple  copies  of  the  same  items  shall  not  be  allowed  in  the  original  or 
destination  lists.  The  push  buttons  from  top  to  bottom  shall  read:  Copy  All,  Copy, 
Remove,  Remove  All. 

5.  The  Add/Copy  push  button  is  only  enabled  when  an  item  is  selected  in  the  original  list. 
The  Remove  push  button  is  only  enabled  when  an  item  is  selected  in  the  destination  list. 
The  Add/Copy  All  and  Remove  All  push  buttons  are  always  enabled  unless  there  are  no 
items  in  the  original  or  destination  lists  respectively.  If  an  item  is  selected  in  the  original 
list,  the  Add/Copy  button  shall  be  the  default.  If  an  item  is  selected  in  the  destination  list, 
the  Remove  button  shall  be  the  default. 

6.  Double  clicking  an  object  in  either  list  shall  move  or  copy  it  to  the  other  list. 

7.  The  Remove  button  shall  be  enabled  and  the  Add  button  shall  be  disabled  if  an  item  in 
the  destination  list  is  the  only  selected  item. 

8.  The  Add  button  shall  be  enabled  and  the  Remove  button  shall  be  disabled  if  an  item  in 
the  source  list  is  the  only  selected  item. 

9.  The  user  shall  not  be  allowed  to  remove  an  item  from  the  source  list. 

10.  Moving  an  item  from  the  source  list  to  the  destination  list  in  a  list-to-list  transfer  box 
shall  not  permanently  remove  the  item  from  the  source  list. 

1 1 .  List-to-list  transfer  windows  shall  support  drag  transfer  actions  (drag  and  drop)  from  one 
list  to  another. 

12.  The  Add  and  Remove  buttons  shall  include  a  graphic  showing  the  direction  of  transfer. 
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Source 


CSFAB,  TBM,  UCA. 

18.5  Message  handling 

18.5.1  Message  handling  windows 

1.  Except  for  broadcast  communication  systems,  the  transmitter  of  each  message  in  inter¬ 
user  communications  shall  be  identified  automatically. 

2.  Message  preparation  windows  shall  follow  the  same  design  as  data  entry  windows. 

3.  Users  shall  be  given  basic  message  header  fields  that  are  supported  in  specifying  the 
message  address. 

4.  Option  menus  may  available  for  selecting  from  limited  sets  of  frequently  used  terms. 

5.  When  replying  to  a  message,  the  appropriate  addressee(s)  shall  be  provided 
automatically. 

6.  Users  shall  have  the  capability  to  build  and  maintain  lists  of  common  addresses  and  select 
from  these  lists  when  preparing  messages,  if  that  functionality  is  required. 

7.  If  functionality  is  required  by  an  application,  addresses  are  checked  prior  to  transmission; 
users  can  correct  errors  before  sending. 

8.  Preformatted  standard  forms  are  available  and  format  control  during  entry  is  automatic. 

9.  Users  shall  be  able  to  specify  data,  incorporate  data  files,  and  save  during 
preparation/completion. 

10.  Each  individual  data  group  or  message  shall  contain  a  descriptive  title,  phrase,  word  or 
similar  device  to  designate  the  content  of  the  group  or  message. 

1 1 .  The  notification  of  the  message  (or  alert)  shall  indicate,  at  minimum,  an  indication  of  the 
number  of  alerts  in  each  category  (e.g.,  flash  messages,  system  messages,  or  tactical 
messages). 


Source 

TBM,  UCA. 

18.5.2  Message  transmission 

1 .  Message  transmission  procedures  shall  be  designed  to  minimize  the  user  actions  required. 

2.  Users  shall  have  the  capability  to  initiate  message  transmission  directly  (e.g.,  select  a 
transmit  push  button)  or  to  set  a  transmission  time. 
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3.  If  a  message  cannot  be  sent  immediately,  it  shall  be  queued  automatically. 

4.  If  functionality  is  required  by  an  application,  users  may  assign  message  priorities  and 
cancel  or  terminate  a  transmission. 

5.  Status  feedback  shall  be  available  that  confirms  messages  sent  and  indicates  failures. 

6.  Users  shall  be  able  to  specify  what  feedback  they  want  to  receive;  an  automatic  log  of 
this  information  shall  be  maintained. 

7.  If  functionality  is  required  by  an  application,  undelivered  messages  are  saved  in  the  event 
that  there  is  transmission  failure. 


Source 

TBM,  MH761. 

18.5.3  Message  receipt 

1 .  Users  shall  be  informed  when  high-priority  messages  are  received. 

2.  Message  notification  shall  not  interrupt  operator  tasks,  but  shall  provide  an  indication  of 
urgency. 

3.  The  presence  of  non-system  generated  messages  that  do  not  require  immediate  operator 
intervention  shall  be  indicated. 

4.  The  messages  shall  be  presented  in  order  of  priority  followed  by  the  most  recently 
received  messages. 

5.  The  highest  priority  messages  shall  be  indicated  with  a  colour  coded  with  a  red  (or 
magenta)  symbol  in  the  message  notification  area. 

6.  The  title  bar  of  a  message  window  shall  be  colour  coded  to  match  the  priority  code  of  the 
message  (Red  for  Flash  messages). 

7.  If  functionality  is  required  by  an  application,  incoming  messages  shall  be  automatically 
queued  by  time  and  priority;  logs  shall  be  maintained. 

8.  Users  can  review  summary  information,  display  messages,  save/file,  and  discard. 

9.  A  message  shall  be  displayed  in  a  text  window  and  users  can  scroll,  save,  and  print  the 
message. 

10.  During  login,  a  system  shall  provide  users  with  a  list  of  new  messages  received. 

1 1 .  Data  transmission  functions  shall  be  integrated  with  other  information  handling  functions 
within  a  system.  A  user  shall  be  able  to  transmit  data  using  the  same  computer  system 
and  procedures  used  for  general  entry,  display,  and  other  processing  of  data. 
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12.  Procedures  for  preparing,  sending  and  receiving  data  and  messages  shall  be  consistent 
from  one  transaction  to  another,  and  consistent  with  procedures  for  other  information 
handling  tasks. 

13.  The  data  transmission  procedures  shall  minimize  memory  load  on  the  users  by  providing 
computer  aids  for  automatic  insertion  of  standard  information,  such  as  headers  and 
distribution  lists. 

14.  Users  shall  be  able  to  interrupt  message  preparation,  review,  or  disposition  and  then 
resume  any  of  those  tasks  from  the  point  of  interruption. 

15.  Where  message  formats  conform  to  a  defined  standard  or  are  predictable  in  other  ways, 
stored  forms  shall  be  provided  to  aid  users  in  message  preparation. 

16.  Users  shall  be  able  to  incoiporate  an  existing  data  file  in  a  message,  or  to  combine  several 
files  into  a  single  message  for  transmission  and  to  combine  stored  data  with  new  data 
when  preparing  messages  for  transmission.  It  shall  not  be  necessary  to  re-enter  any  data 
already  entered  for  other  purposes. 

17.  When  users  must  specify  the  address  for  messages,  prompting  shall  be  provided  to  guide 
the  user  in  the  process. 

18.  Users  shall  be  provided  with  an  on-line  directory  showing  all  acceptable  forms  of 
message  addressing  for  each  destination  in  the  system,  and  for  links  to  external  systems. 

19.  Computer  aids  shall  be  provided  so  that  a  user  can  search  an  address  directory  by 
specifying  a  complete  or  partial  name.  It  shall  also  be  possible  to  extract  selected 
addresses  from  a  directory  for  direct  insertion  into  a  header  in  order  to  specify  the 
destination(s)  for  a  message. 


Source 

TBM,  MH761,  MS1472F,  UCA. 

18.6  Spellchecking 

Spell  checking  can  highlight  erroneous  entries  to  the  user  as  well  as  provide  suggestions  for 
corrections.  For  instance,  Microsoft  Word  provides  the  following  dialog  box  (Figure  30)  to  assist 
the  user  with  checking  the  spelling  of  a  text  document. 
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Figure  30:  Example  of  a  spell  checker  window. 

1.  Spell  checking  displays  and  operation  shall  be  consistent  with  Microsoft  Windows  styles. 

2.  A  task  window  used  to  perform  spell  checking  on  a  text  document  or  message  segment 
shall  display  the  unknown  word  to  the  user  in  an  uneditable  text  field. 

3.  An  unknown  word  identified  by  the  spell  checker  shall  appear  in  an  editable  text  field  so 
that  the  user  can  edit  the  unknown  word. 

4.  The  system  shall  provide  a  default  dictionary  of  common  words,  abbreviations,  etc.,  used 
in  the  application.  This  dictionary  shall  be  tailored  for  the  application  task. 

5.  The  user  shall  be  able  to  view  suggestions  from  the  dictionary  on  how  to  correct  an 
unknown  word. 

6.  The  user  shall  be  able  to  select  a  word  from  the  list  of  suggestions  and  have  the  option  of 
editing  the  word  before  replacing  the  unknown  word. 

7.  The  user  shall  have  the  option  of  replacing  all  instances  of  a  given  unknown  word  with 
the  specified  corrected  word  or  replacing  each  instance  individually.  If  a  user  chooses  to 
globally  replace  all  instances  of  a  given  unknown  word,  the  spell  checker  shall 
automatically  replace  the  word  without  acknowledgment  from  the  user  and  shall  not 
interrupt  the  spell  checking  process. 

8.  The  user  shall  be  allowed  to  skip  an  unknown  word  without  changing  it. 

9.  The  user  shall  be  given  the  option  to  skip  all  instances  of  an  unknown  word  for  the 
remainder  of  the  document  or  to  skip  the  current  instance  only. 

10.  The  user  shall  be  able  to  specify  the  direction  of  the  spell  check  relative  to  the  current 
position. 
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1 1 .  The  user  shall  be  able  to  cancel  the  spell  check  operation  at  any  time. 

12.  Spelling  and  other  common  errors  shall  not  produce  valid  system  commands  or  initiate 
transactions  different  from  those  intended.  When  possible,  the  system  shall  recognize 
common  misspellings  of  commands  and  execute  the  commands  as  if  spelling  had  been 
correct. 

13.  Computer-corrected  commands,  values,  and  spellings  shall  be  displayed  and  highlighted 
for  user  confirmation. 


Source 

TBM,  MS1472F,  UCA. 

18.7  Printing 

Print  dialog  boxes  allow  the  user  to  specify  print  settings  such  as  the  capability  to  print  a  single 
page,  or  a  sequence  of  pages,  by  specifying  the  page  numbers.  Figure  31  illustrates  a  Microsoft 
Word  dialog  box  with  the  ability  to  adjust  printer  settings.  Printer  settings  depicted  here  include 
the  choice  of  output  printer,  page  range,  number  of  copies,  and  zoom  size. 


Figure  31:  Example  of  a  print  dialog. 

1.  The  design  details  of  the  printer  controls  shall  be  consistent  with  MSWUE  (see  MSWUE, 
Chapter  9)  guidelines. 

2.  Users  shall  be  able  to  save,  access,  retrieve,  rename,  and  print  text  documents. 
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3.  Users  shall  be  provided  the  capability  to  specify  the  portions  of  the  document  to  be 
printed  and  the  printer  on  which  the  document  is  printed. 

4.  When  printing  text,  users  shall  be  allowed  to  select  among  available  output  formats  (e.g., 
line  spacing,  character  size,  margin  size,  heading,  and  footing)  and  to  specify  the  pages  of 
a  document  to  be  printed. 

5.  The  user  shall  have  the  capability  to  obtain  a  paper  copy  of  the  contents  of  the 
alphanumeric  or  digital  graphic  display  in  those  systems  where  the  following  conditions 
apply: 

■  Mass  storage  is  restricted. 

■  Mass  stored  data  can  be  lost  by  power  interruption. 

■  Record  keeping  is  required. 

6.  The  user  shall  be  able  to  print  a  display  by  simple  request,  without  having  to  take  a  series 
of  other  actions  first.  An  example  of  an  unacceptable  series  of  action  is:  calling  for  the 
display  to  be  filed,  specifying  a  filename  then  calling  for  a  print  of  that  named  file. 

7.  The  user  shall  have  the  capability  to  print  a  single  page,  or  sequence  of  pages,  by 
specifying  the  page  numbers. 

8.  The  system  shall  acknowledge  the  print  command  and  provide  the  status  of  the  printer 
and  queue. 

9.  The  printer  control  shall  permit  the  operator  to  elect  to  print  screen  capture  of  the  tactical 
display,  if  required. 


Source 

TBM,  MS1472F,  MSWUE,  UCA. 

18.8  Imagery  manipulation 

18.8.1  Imagery  appearance 

1 .  An  imagery  window  shall  contain  an  imagery  display  and  a  set  of  tools  for  manipulating 
the  image. 

2.  An  imagery  window  shall  include  identifying  information  about  the  image  displayed  and 
this  information  shall  be  displayed  in  a  standard  location. 

3.  When  an  entire  image  does  not  fit  on  a  screen,  the  users  shall  be  provided  with  the 
capability  to  scroll,  pan,  and  zoom. 

4.  An  imagery  window  shall  contain  resize  handles  and  resizing  the  window  shall  have  an 
effect  on  the  image  contained  in  the  window. 

5.  An  imagery  system  shall  permit  users  to  access  and  retrieve  an  image  for  display  from  a 
directory  of  images. 
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6.  An  imagery  system  shall  permit  users  to  specify  the  name  of  the  image  or  search  the 
directory  of  images  for  images  matching  user-defined  criteria,  including  wild  card 
searches. 

7.  An  imagery  system  shall  permit  users  to  print  in  full-resolution  or  low-resolution  an 
image  displayed  in  an  imagery  window. 


Source 

TBM. 

18.8.2  Imagery  viewing  functions 

1 .  An  imagery  window  shall  permit  users  to  roam  or  pan  an  image  in  both  the  horizontal 
and  vertical  direction. 

2.  When  panning  or  roaming  an  image,  automatic,  jump,  manual,  and  patterned  roam 
control  shall  be  available  and  an  imagery  system  shall  permit  users  to  specify  the  rate, 
direction,  and  area  of  interest  as  appropriate. 

3.  As  users  pan  or  roam  an  image,  the  imagery  system  shall  permit  users  to  tag  specific 
areas  of  interest  for  later  recall  while  the  image  remains  in  the  display  area. 

4.  An  imagery  system  shall  permit  users  to  zoom  an  image  in  predefined  increments  or  in 
user-defined  increments. 

5.  An  imagery  system  shall  support  image  chipping.  Image  chipping  allows  users  to  select 
and  designate  regions  of  an  image  for  storage. 

6.  An  imagery  system  shall  permit  users  to  create  and  manipulate  annotations  to  display 
with  an  image.  Annotations  shall  include  text,  lines,  icons,  geometric  shapes,  colours,  and 
patterns. 

7.  Image  annotations  shall  be  edited,  deleted,  repositioned,  resized,  saved,  and  retrieved 
without  altering  the  underlying  imagery  data. 

8.  When  an  image  is  manipulated  (e.g.,  resized,  rescaled,  etc.),  the  scale  and  orientation  of 
image  annotations  shall  be  adjusted  to  accommodate  the  changes.  However,  textual 
annotations  shall  remain  constant. 


Source 

TBM. 


18.8.3  Advanced  imagery  viewing  functions 

1 .  An  imagery  system  shall  provide  image  enhancement  filtering  capabilities  to  control  the 
dynamic  range  of  imagery  data  by  modification  of  intensity  and  contrast. 

2.  An  imagery  system  shall  permit  users  to  select  and  examine  (e.g.,  zoom,  roam)  a  region 
of  interest  within  an  image  leaving  the  remainder  of  the  image  unaffected. 
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3.  Imagery  windows  shall  provide  measurement  functions  for  computing  lengths,  areas,  and 
volumes  from  dimensions  or  angles.  Imagery  windows  shall  also  provide  the  capability  to 
perform  isotropic  pixel  correction  (i.e.,  convert  rectangular  pixels  to  square  pixels  for 
display  purposes). 

4.  Imagery  windows  shall  permit  users  to  create  a  mirror  view  of  the  image  so  the  image 
can  be  adjusted  if  the  negative  was  inverted  when  scanned. 

5.  Imagery  windows  shall  provide  a  default  image  rotation  where  vertical  objects  are 
oriented  toward  the  top  of  a  window  and  an  automatic  north  rotation  where  north  is 
oriented  at  the  top  of  the  window.  Imagery  windows  shall  also  permit  users  to  rotate 
images  in  user-defined  increments. 

6.  When  an  image  is  manipulated  in  an  image  window,  the  scale  and  orientation  of 
annotations  shall  be  adjusted  according  to  the  type  and  nature  of  the  symbol. 

7.  An  imagery  system  shall  permit  users  to  plot  user-selected  geographic  data  on  the  image, 
including  frame-by-frame  plotting  to  animate  the  data  in  either  a  forward  or  reverse  time 
direction. 

8.  An  imagery  system  shall  permit  users  to  register  (i.e.,  transform  an  image  so  that  it  aligns 
with  either  another  image  or  a  map  projection)  geo-referenced  images  acquired  from  the 
same  or  different  sensors  and  display  them  together. 

9.  An  imagery  system  shall  permit  users  to  perform  concurrent  geometric  manipulations  on 
separate  geo-referenced  windows  that  have  overlapping  geographic  coverage. 

10.  Users  shall  be  able  to  "slave"  together  multiple  geo-referenced  windows  and  manipulate 
(e.g.,  roam,  zoom,  rotate)  all  the  slaved  windows  concurrently  and  relatively  (i.e.,  with 
the  window  centres  maintained  at  a  common  centre  latitude/longitude  position),  despite 
differences  in  the  amount  and  distance  coverage  between  windows. 


Source 

TBM. 
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Evaluation  methods  and  measures 


Design  verification: 

•  Verification  of  ease  of  use  and  design  consistency  of  all  functions  and  formats  in  the  OMI. 
Operator  performance: 

•  Objective  assessment  of  use  and  usefulness  of  all  special  functions  and  formats. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  perceptions  of  usability  and  utility 
of  all  special  functions  and  formats  in  the  OMI  and  ESS. 
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19  Graph  display 


Graphs  can  be  used  to  present  assessment  of  trend  information,  spatially  structured  data,  time 
critical  information  or  relatively  imprecise  information.  There  are  a  number  of  types  of  graphs; 
an  example  of  a  line  graph  and  a  bar  graph  is  presented  in  Figure  32Figure  33. 


Month 

Figure  32:  Example  of  a  line  graph. 
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Figure  33:  Example  of  a  bar  graph. 


19.1  Graph  display  characteristics 

1.  Displays  of  graphs  shall  be  used  to  present  assessment  of  trend  information,  spatially 
structured  data,  time  critical  information  or  relatively  imprecise  information. 

2.  When  users  must  compare  graphic  data  across  a  series  of  charts,  the  same  scale  shall  be 
used  for  each  chart. 
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3.  The  window  shall  include  a  title  and  shall  be  sized  so  that  the  entire  graph  is  visible. 

4.  Users  shall  not  have  to  scroll  or  resize  a  graph  display  window  to  view  its  contents. 

5.  Charts  and  axes  shall  be  clearly  labelled,  and  important  information  shall  be  highlighted. 

6.  When  a  user  must  compare  graphed  data  to  some  significant  level  or  critical  value,  a 
reference  index  or  baseline  shall  be  included  in  the  display. 

7.  When  precise  reading  of  a  graph  may  be  required,  the  capability  shall  be  provided  to 
supplement  the  graphic  representation  with  the  actual  numeric  values. 

8.  Where  graphs  are  presented,  only  a  single  scale  shall  be  shown  in  each  axis,  rather  than 
including  different  scales  for  different  curves  in  the  graph.  If  interpolation  must  be  made 
or  where  accuracy  of  reading  graphic  data  is  required,  the  user  shall  be  provided  with 
computer  aids. 

9.  Linear  scales  shall  be  used  in  preference  to  logarithmic  or  other  non-linear  scales. 

10.  Gradations  shall  be  at  standard  intervals;  intervening  gradations  shall  be  consistent  with 
the  labelled  scale. 

11.  Labels  shall  be  used  instead  of  legends  or  keys  to  identify  the  data. 

12.  The  labels  shall  be  oriented  horizontally  and  located  next  to  the  data  being  referenced. 

13.  Gridlines  shall  be  unobtrusive  and  shall  not  obscure  the  data  presented  in  the  graph. 

14.  Users  shall  be  provided  the  capability  to  display  or  suppress  gridlines  as  desired. 

15.  The  same  coding  scheme  shall  be  used  consistently  throughout  an  application. 

16.  Users  shall  be  able  to  re-draw  multiple  graphs  using  the  same  scale  to  facilitate 
comparison. 

17.  For  precise  values,  users  shall  be  able  to  display  the  actual  values  on  the  graph  and  to 
zoom. 


Source 

TBM,  D1SA,  MH761,  MS1472F. 

19.2  Line  graphs 

1.  Line  graphs  or  curves  shall  be  used  for  displaying  relations  between  two  continuous 
variables.  This  includes  trend  information,  spatially  structured  information,  time  critical 
information,  or  relatively  imprecise  information. 

2.  The  axes  of  the  graph  shall  be  clearly  labelled  and  include  the  unit  of  measurement  as 
appropriate. 
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3.  The  labels  shall  be  in  mixed-case  letters  and  oriented  left  to  right  for  normal  reading. 

4.  The  horizontal  (x-axis)  shall  be  used  to  plot  time  or  the  postulated  cause  and  the  vertical 
(y-axis)  shall  be  used  to  plot  a  caused  effect  when  these  variables  are  appropriate. 

5.  Minimum/maximum  values  shall  be  shown  on  each  axis,  with  up  to  nine  intermediate 
markings. 

6.  The  starting  point  of  an  axis  shall  be  zero,  with  the  gradations  indicated  in  whole 
numbers  unless  zero  is  an  inappropriate  starting  point  and  whole  numbers  are 
inappropriate. 

7.  When  graphed  data  represents  only  positive  numbers,  the  graph  shall  be  displayed  with 
the  origin  at  the  lower  left.  When  data  includes  negative  values  and  the  axis  extend  in 
both  directions  from  a  zero  point,  the  origin  shall  be  displayed  in  the  centre  of  the  graph. 

8.  Each  line  or  curve  on  a  graph  shall  be  labelled  and  coded  and  critical  or  abnormal  data 
shall  be  coded. 

9.  Multiple  trend  lines  shall  be  presented  on  a  single  graph. 

10.  Where  users  must  evaluate  the  difference  between  two  sets  of  data,  that  difference  shall 
be  plotted  directly  as  a  curve  in  its  own  right,  rather  than  requiring  users  to  compare 
visually  the  curves  that  represent  the  original  data  sets. 


Source 

TBM,  MH761,  MS1472F. 

19.3  Surface  charts 

1.  When  curves  represent  all  of  the  portions  of  a  whole,  surface  charts  shall  be  used  to 
display  aggregated  amounts. 

2.  The  area  defined  below  the  curves  or  lines  in  a  surface  chart  shall  be  textured,  shaded,  or 
coloured. 

3.  Data  categories  in  a  surface  chart  shall  be  ordered  such  that  the  least  variable  curves  are 
displayed  at  the  bottom  and  the  most  variable  at  the  top. 

4.  If  space  is  available,  labels  shall  be  placed  within  the  textured  or  shaded  bands,  the  labels 
shall  be  easily  readable  within  the  bands. 


Source 

TBM,  D1SA,  MH761. 
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19.4  Bar  charts  and  histograms 

1.  Bar  charts  shall  be  used  when  comparing  a  single  measure  (e.g.,  number  of  eligible 
recruits,  thousands  of  dollars,  etc.)  across  a  set  of  several  entitles  (e.g.,  geographic 
regions,  level  of  education,  religion,  etc.)  or  for  a  variable  sampled  at  discrete  intervals. 
Histograms  (bar  graphs  without  spaces  between  bars)  shall  be  used  when  there  are  a  great 
many  entities  or  intervals  to  be  plotted. 

2.  In  a  related  series  of  bar  graphs,  a  consistent  orientation  of  the  bars  (vertical  or 
horizontal)  shall  be  adopted. 

3.  When  data  must  be  compared,  bars  shall  be  adjacent  to  one  another.  Adjacent  bars  shall 
be  spaced  such  that  a  direct  visual  comparison  can  be  made  without  eye  movements 

4.  A  reference  index  shall  be  provided  when  displayed  values  must  be  compared  with  some 
critical  value. 

5.  Use  of  iconic  representations  of  quantitative  information  (e.g.,  using  a  silhouette  of  a 
person  to  represent  1000  people)  shall  be  avoided. 

6.  When  bars  are  presented  in  pairs,  they  shall  be  labelled  as  a  unit,  with  a  legend  provided 
that  distinguishes  between  the  bars. 


Source 

TBM,  D1SA,  MH761,  MS1472F. 

19.5  Flowcharts 

1.  Flow  charts  shall  be  used  for  a  schematic  representation  of  sequences  or  processes. 

2.  The  steps  in  a  flow  chart  shall  be  presented  in  a  logical  order  (e.g.,  a  process  by  sequence 
of  activity  or  by  decreasing  importance  to  mission  success). 

3.  If  there  is  no  inherent  logic,  the  steps  shall  be  ordered  to  minimize  the  size  of  the  flow 
chart. 

4.  The  path  indicated  in  the  flow  chart  shall  be  left-to-right,  top-to-bottom,  or  clockwise. 

5.  Each  decision  point  in  the  flow  chart  shall  contain  a  single,  simple  decision. 

6.  The  flow  chart  elements  and  lines  shall  be  consistently  coded  to  assist  in  understanding. 

7.  The  flow  chart  shall  provide  direction  indicators  to  indicate  the  sequence  to  be  followed. 

8.  A  legend  shall  describe  each  element  and  code;  critical  information,  and/or  steps  shall  be 
highlighted. 


Source 
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TBM,  DISA,  MH761. 


19.6  Manipulation  and  creation  of  graphical  data 

19.6.1  Manipulation  of  graphical  data 

1.  When  an  application  allows  users  to  manipulate  graphical  data,  the  application  shall 
allow  the  following: 

■  Users  shall  be  able  to  select  and  edit  graphical  object  attributes  (e.g.,  colour,  line 
thickness,  and  font  size). 

■  Users  shall  be  able  to  enlarge  or  reduce  graphical  object  sizes. 

■  Users  shall  be  able  to  fill  enclosed  graphical  areas  with  colour  and  patterns. 

■  Users  shall  be  able  to  remove  and  restore  selected  elements  of  the  display. 

2.  If  appropriate,  applications  shall  automatically  align  graphical  objects  to  an  invisible  rule 
or  grid  structure.  Alignment  shall  be  able  to  be  turned  on  or  off  at  the  discretion  of  the 
user. 

3.  For  most  graphics  data  entry,  pointing  shall  be  a  dual  action,  with  the  first  action 
positioning  the  cursor  at  a  desired  position  and  the  second  action  confirming  that  position 
to  the  computer.  An  exception  may  be  a  design  that  allows  "free-hand"  drawing  of 
continuous  lines. 

4.  Drawn  objects  shall  be  able  to  be  easily  repositioned,  duplicated,  and  deleted. 

5.  When  appropriate,  users  shall  be  able  to  group  separate  objects  into  a  single,  grouped 
object  (so  that  separate  objects  may,  for  example,  be  moved  as  a  unit,  or  so  that  a 
complex  object  can  be  incrementally  drawn). 

6.  When  editing  graphic  data,  users  shall  be  provided  with  the  capability  to  change  the  size 
(scale)  of  any  selected  element  on  the  display,  rather  than  delete  and  recreate  the  element 
in  a  different  size. 

7.  A  copy  of  the  original  graphics  is  retained  until  users  confirm  that  the  objects  are  to  be 
changed.  The  objects  are  not  modified  automatically  as  users  change  them. 

8.  Objects  are  displayed  as  they  will  be  printed  (or  a  print  preview  option  is  available  to  see 
this  format). 


Source 

TBM,  MH761,  MS1472F. 

19.6.2  Creating  graphical  data 

1.  The  system  shall  provide  a  set  of  appropriate  drawing  tools.  Whenever  drawing  tools  are 
provided  they  shall  use  the  icons  and  options  described  in  MSWUE. 


DRDC  Toronto  TR  2009-062 


201 


2.  Drawing  tools  shall  provide  the  operator  with  easy  means  to  draw  required  tactical 
objects.  New  drawing  tools  and  icons  shall  be  provided  if  required. 

3.  Objects  shall  emerge  as  they  are  drawn. 

4.  Applications  shall  automatically  complete  figures  (e.g.,  closure  of  a  polygon)  upon 
demand  and  shall  draw  lines  between  user-specified  points. 

5.  Users  shall  be  able  to  draw  objects  such  as  lines,  rectangles,  ovals,  and  arcs. 

6.  When  line  drawing  is  required,  users  shall  be  provided  with  aids  for  drawing  straight  line 
segments.  When  line  segments  must  join  or  intersect,  computer  aids  shall  be  provided  to 
aid  in  such  connection. 

7.  When  a  user  must  draw  figures,  computer  aids  shall  be  provided  for  that  purpose  (e.g., 
templates,  tracing  techniques,  stored  forms). 

8.  When  appropriate,  users  shall  be  able  to  constrain  line  drawing  to  exactly  vertical  or 
horizontal.  For  precise  drawing,  users  shall  be  able  to  specify  their  geometric  relations  to 
other  lines  (e.g.,  parallel  or  perpendicular  to  another  line). 


Source 

TBM,  MH761,  MS1472F,  MSWUE,  UCA. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  ease  of  use  and  design  consistency  of  graphical  information  and  graphics 
tools  in  the  OM1. 

Operator  performance: 

•  Objective  assessment  of  use  and  usefulness  of  graphical  information  and  graphics  tools 
through  usability  testing. 
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Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  perceptions  of  usability  and  utility 
of  graphical  information  and  graphics  tools  in  the  OMI  and  ESS. 
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20  Tactical  graphics 


20.1  Tactical  graphics  characteristics 

1.  Colour  shall  only  be  used  when  it  will  increase  operator  performance  or  situational 
awareness. 

2.  Colour  shall  be  used  as  a  redundant  cue  to  segregate  tracks  in  the  tactical  display. 

3.  The  maximum  number  of  colours  for  symbols  and  their  associated  tracks  shall  be  five. 

4.  When  the  operator's  tasks  do  not  require  the  search  for  objects  and  if  colour  will  not 
provide  any  added  information  to  the  operator,  then  grey  will  probably  be  the  best  colour 
choice  for  that  object.  Objects  that  are  colour  coded  shall  also  be  redundantly  coded  by 
some  other  means  such  as  fill  pattern  or  shape. 

5.  The  number  of  coding  shapes  shall  be  limited  to  five.  Simple  geometric  shapes  are 
recommended.  Designers  shall  follow  the  standard  notation  of  pointed  shapes  meaning 
hostile  or  danger  and  round  shapes  meaning  friendly  or  OK;  the  over-riding  source  for 
design  of  coded  shapes  shall  be  the  NTDS,  or  other  conventions  as  specified. 

6.  Shapes  (and  colours)  for  track  symbols,  and  other  symbology,  shall  follow  the  NTDS 
conventions  with  the  caveat  that  the  Canadian  Forces  may  require  STANAG  4420  or 
Military  Standard  2525  (Common  Warfighting  Symbology).  Without  further  research 
only  those  elements  of  STANAG  4420  or  Military  Standard  2525  that  correspond  to  the 
current  NTDS  symbols  should  be  used. 

7.  A  maximum  of  two  different  sizes  shall  be  used  to  code  information. 

8.  Where  size  difference  between  symbols  is  employed,  the  major  dimension  of  the  larger 
shall  be  not  less  than  150%  of  the  major  dimension  of  the  smaller. 

9.  Position  is  generally  reserved  to  display  geographic  information.  Position  shall  not  be 
used  to  determine  quantitative  information  but  can  be  used  to  display  qualitative 
information.  Qualitative  judgments  are  generally  a  relative  judgment  task  (e.g.,  one 
symbol  is  higher,  closer,  etc.  than  another  symbol). 

10.  When  special  symbols  are  used  to  signal  critical  conditions,  they  shall  be  used  for  only 
that  puipose. 

1 1 .  Limit  the  number  of  different  orientations  to  twelve  (like  a  clock)  and  preferably  eight. 
This  code  shall  generally  be  reserved  for  displaying  directional  information  but  maybe 
combined  with  shape  information  to  further  designate  a  symbol  (e.g.,  a  triangle  means 
hostile;  up  is  a  hostile  air,  up  and  down  is  a  hostile  surface,  and  down  is  a  hostile 
subsurface).  Symbols  of  the  same  shape  shall  have  some  common  bond  regardless  of 
orientation  (e.g.,  all  triangles  are  hostile). 
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12.  Alphanumerics  shall  be  used  with  multiple  (greater  than  eight)  states  or  levels  that  must 
be  absolutely  distinguished.  For  memory  purposes  the  number  of  "chunks"  in  a  code  shall 
be  limited  to  four.  Case-sensitive  coding  shall  be  avoided  except  for  passwords. 

13.  Only  two  levels  of  intensity  (brightness)  shall  be  used.  Brightness  shall  only  be  used  as  a 
code  if  the  objects  coded  are  adjacent.  Each  level  shall  be  separated  from  the  nearest 
other  level  by  not  less  than  a  2: 1  ratio. 

14.  An  object  coded  with  the  lesser  of  two  intensities  shall  be  less  important  for  that 
particular  task  and  shall  not  create  a  problem  if  ignored  or  overlooked  by  the  operator. 

15.  Reverse  video  shall  not  be  used  for  coding. 

16.  The  display  shall  provide  a  visual  distinction  between  system-generated  and  manual 
upgrades  of  a  track. 


Source 

CSFAB,  MS1472F,  UCA. 

Discussion 

G7.  CSFAB  and  MS  1472F  limit  the  number  of  sizes  to  three. 

G13.  Absolute  brightness  is  difficult  to  interpret.  Using  brightness  as  a  code  shall  be  avoided. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  of  ease  of  use  and  design  consistency  of  tactical  graphics  in  the  OM1. 

Operator  performance: 

•  Objective  assessment  of  use  and  usefulness  of  tactical  graphics  through  usability  testing. 

•  Objective  assessment  of  speed  and  accuracy  of  detection  and  recognition  of  critical  objects 
and  tactical  information  on  a  tactical  display. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  perceptions  of  usability  and  utility 
of  tactical  graphics  in  the  OM1  and  ESS. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  situation  awareness  of  the  tactical 
picture. 


DRDC  Toronto  TR  2009-062 


205 


21  Maps  and  situation  display 


21.1  Radar 

21.1.1  Single  radar 

1 .  Returns  from  a  single  radar  shall  normally  be  in  grey  scale  with  stronger  returns  depicted 
by  brighter  grays.  Any  number  of  grey  scale  levels  may  be  used  but  more  than  1 6  to  20 
levels  will  have  diminishing  returns.  Any  sections  not  covered  by  radar  shall  be  outlined 
in  black. 

Source 

CSFAB. 

21.1.2  Multiple  Radars 

1 .  Separate  radars  may  be  designated  by  a  separate  colour  return  or  by  a  coloured  border 
around  its  area  of  operation.  If  radars  are  operating  in  the  same  sections,  they  must  be 
given  a  hierarchy  by  the  operator  that  the  system  shall  use  to  determine  layering  of  the 
returns. 

2.  A  maximum  of  three  different  colour  returns  may  be  used  to  depict  separate  radar  returns. 
For  coloured  returns,  use  the  same  hue  and  saturation  while  changing  the  colour’s 
brightness  to  display  the  radar  return  strength.  Stronger  returns  shall  be  depicted  by 
brighter  colours.  Any  sections  not  covered  by  radar  shall  be  outlined  in  black. 

3.  A  maximum  of  six  different  coloured  borders  may  be  used.  The  coloured  border  is  placed 
around  the  section  where  the  radar  is  operating.  The  border  may  also  be  made  to  fade  at 
the  same  rate  as  the  radar  return.  If  multiple  radars  overlap,  the  outlines  of  higher  altitude 
radars  shall  be  to  the  inside  of  other  radars.  The  radar  return  for  all  radars  with  coloured 
borders  shall  be  displayed  as  grey  scale  levels  with  stronger  returns  being  brighter. 

4.  The  operator  shall  be  able  to  independently  control  both  the  fade  and  sweep  rates  for  each 
radar. 


Source 

CSFAB. 

21.2  Tactical  displays 

21.2.1  Tactical  display  characteristics 

1.  The  tactical  picture  display  for  the  CCS  shall  occupy  no  less  than  60%  of  the  complete 
display  area  on  the  screen.  If  multiple  monitors  are  implemented  for  a  single  console, 
then  the  tactical  picture  display  shall  occupy  no  less  than  60%  of  the  complete  display 
area  on  the  primary  screen. 
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2.  A  tactical  display  window  may  contain  both  a  tactical  display  and  a  set  of  controls  for 
manipulating  the  display. 

3.  A  tactical  display  area  shall  include  identifying  information  about  the  tactical  display 
(e.g.,  map  name,  area,  scale)  in  the  title  bar. 

4.  Status  information  (e.g.,  coordinates,  "drawing  map",  "updating  map")  shall  be  provided. 

5.  The  tactical  display  window  shall  be  supplemented  by  windows  or  information  areas  that 
provide  amplifying  information  about  selected  objects  and  symbols. 

6.  The  tactical  display  shall  be  initially  presented  in  a  default  range  that  is  appropriate  to  the 
operator  position  to  provide  the  operator  an  overall  tactical  picture. 

7.  Users  shall  select  and  deselect  symbols  on  the  tactical  display  using  standard  selection 
methods. 

8.  Labels  shall  be  able  to  be  applied  to  any  object  on  the  tactical  display.  All  labels  are 
global  so  that  once  an  object  is  given  a  label;  other  operators  must  use  this  label.  As  a 
default  the  label  shall  only  be  displayed  in  the  amplification  window,  but  each  user  shall 
have  the  ability  to  also  display  any  label  on  the  map.  In  either  case,  the  label  shall  always 
be  displayed  in  the  amplification  window.  Only  the  originator  and  authorized  operators 
may  alter  global  labels. 

9.  The  tactical  display  shall  be  a  fixed  window  and  take  on  all  characteristics  of  fixed 
windows. 

10.  The  tactical  display  shall  be  located  on  the  right-hand  side  of  the  monitor. 

1 1 .  The  tactical  display  shall  include  a  means  by  which  users  can  obtain  help  in  identifying 
unknown  symbols  or  other  object  information. 


Source 

CSFAB,  TBM,  D1SA,  UCA. 

Discussion 

Gl.  The  Halifax-Class  CCS  tactical  picture  display  is  approximately  60%  of  the  display  area 
on  a  single  screen. 

G10.  The  tactical  display  should  be  located  near  an  anchor  point  on  the  screen.  The  right-hand 
side  was  selected  to  retain  consistency  with  the  Halifax-Class  CCS  OMI. 

21.2.2  Tactical  tools 

1.  Controls  that  affect  the  tactical  display  map,  such  as  range  selection  and  overlays,  shall 
be  located  in  an  area  just  below  the  tactical  display. 
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2.  The  operator  shall  be  able  to  enter  geographic  points  (such  as  lat/long)  to  identify 
locations  for  graphic  elements.  Examples  include  specifying  the  location  of  a  specific 
object  or  setting  the  parameters  for  a  geographic  area. 

3.  Tactical  displays  shall  provide  a  distance/azimuth  function  that  calculates  the  distance 
(range)  and  azimuth  (bearing)  between  any  two  selectable  points  or  symbols.  Distance 
shall  be  presented  in  user-selectable  units  (in  feet,  meters,  miles,  nautical  miles,  or 
kilometres).  Azimuth  shall  be  displayed  in  degrees  from  true  North. 

4.  The  software  shall  provide  a  means  to  determine  the  range  and  bearing  between  any  two 
points  on  the  tactical  display.  The  first  point  shall  be  selected  by  the  operator  and  the 
second  point  will  be  the  current  location  of  the  pointer.  A  line  shall  be  drawn  between  the 
first  point  and  the  pointer  location.  As  the  pointer  moves,  the  range  and  bearing 
information  shall  be  updated.  The  bearing  shall  be  given  from  the  first  point  to  the  second 
point. 

5.  Tactical  displays  shall  provide  an  automated  means  for  determining  the  bearing  and  range 
between  points.  If  users  need  to  judge  precise  distances,  computer  aids  may  be  provided. 

6.  Bearing  and  range  lines  shall  display  the  bearing  and  range  (in  that  order)  near  the 
bearing  and  range  line  approximately  1/3  of  the  distance  between  the  two  points  and 
closest  to  the  second  point  chosen. 

7.  The  display  of  bearing  and  range  lines  shall  be  operator-selectable  as  in  an  overlay. 

8.  The  tactical  display  shall  provide  a  position  determination  function  that  calculates  the 
position  of  an  identified  point.  The  point  is  provided  by  latitude  and  longitude,  distance 
(in  feet,  meters,  miles,  nautical  miles,  or  kilometres),  and  an  azimuth.  Coordinates  shall 
be  provided  in  a  user-selectable  coordinate  system  (e.g.,  Universal  Transverse  Mercator, 
latitude/longitude,  or  Military  Grid  Reference  System). 

9.  The  software  shall  provide  a  means  to  determine  the  latitude  and  longitude  location  of  the 
pointer  at  any  location  on  a  tactical  display.  The  software  shall  also  provide  the  bearing 
and  range  of  the  pointer  location  from  Ownship. 

10.  The  software  shall  provide  a  means  to  compute  a  running  distance  along  a  series  of  lines. 
This  would  be  used  to  determine  non-straight  line  distance. 

1 1 .  The  software  shall  provide  a  means  to  determine  an  area  by  defining  a  circle,  rectangle, 
or  polygon  region. 

12.  An  operator  shall  be  able  to  select  a  contact,  input  a  time,  duration  and  bearing  (default  to 
current  bearing)  and  the  software  will  provide  a  predicted  location  for  that  contact 
assuming  its  bearing  does  not  change. 

13.  By  selecting  two  tracks  (or  contacts)  or  one  track  (or  contact)  and  a  fixed  point,  the 
operator  shall  be  able  to  see  dead  reckoned  lines  and  the  location  of  the  closest  point  of 
approach  (CPA). 
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14.  The  tactical  display  shall  provide  a  direction  function  that  allows  users  to  designate 
direction  by  pointer  placement  using  the  pointing  device,  entry  of  bearing  and  elevation 
angles,  or  specification  of  points  of  interest. 

15.  When  tactical  display  location  data  is  frequently  used,  a  constantly  visible  display  of 
coordinates  associated  with  the  pointer  shall  be  displayed  in  appropriate  coordinate  units. 
The  continuous  display  of  location  shall  be  augmented  with  the  capability  to  fix  (point  on 
the  tactical  display)  a  location  to  facilitate  moving  overlay  displays.  If  appropriate  to  the 
application,  the  capability  to  fix  a  location  on  the  display  and  label  it  for  storage,  retrieval 
and  cantering  of  the  display  may  be  provided. 

Source 

CSFAB,  TBM,  D1SA,  UCA. 

21.2.3  Drawing  tools 

1.  The  system  shall  provide  a  set  of  appropriate  drawing  tools.  The  operators  shall  only  be 
provided  with  drawing  tools  that  have  operational  relevance.  Whenever  operationally 
relevant  drawing  tools  are  provided  they  shall  use  the  symbols  and  options  described  in 
MSWUE. 

2.  New  drawing  tools  and  symbols  shall  be  provided  if  required.  Such  tools  shall  provide 
the  operator  with  easy  means  to  draw  the  required  tactical  objects. 

3.  Drawing  tools  shall  include  means  for  the  objects  to  re-size  or  re-locate  according  to 
defined  specification.  For  example,  the  drawing  tool  that  supports  drawing  of  an 
expanding  area  of  interest  must  permit  the  operator  to  specify  the  rate  of  expansion. 

4.  Detailed  specification  of  the  actions  of  drawn  objects  shall  be  operable  from  the  drawing 
tool  and  shall  not  require  additional  menus  to  be  opened. 

5.  When  line  or  figures  must  be  drawn  to  represent  numeric  coordinates,  computer  aids  shall 
include  templates  for  entering  the  coordinates,  and  if  necessary,  selecting  the  appropriate 
units  for  those  coordinates. 

6.  Where  graphic  data  must  be  plotted  in  predefined  standard  formats  (e.g.,  target  areas  on 
maps),  templates  or  skeletal  displays  shall  be  provided  for  those  formats  to  aid  data  entry. 

7.  Map  points  shall  include  a  point  designation  feature  (e.g.,  cross  hairs  or  a  V-shaped 
symbol). 

8.  The  OM1  shall  support  direct  manipulation  of  displayed  objects  on  the  situation  display. 
Examples  include  selecting  drawn  objects  and  moving  or  dropping  them. 


Source 

CSFAB,  D1SA,  MS1472F,  MSWUE,  UCA. 
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Selecting  contacts  or  objects 


21.2.4.1  Primary  hooking 

1 .  Selection  aids  shall  be  available  to  assist  the  user  in  the  visual  location  and  selection  of  a 
symbol  or  graphic  object  in  a  display  with  many  other  closely  spaced  or  overlapping 
objects.  These  aids  shall  include  an  interactive  track  group  list,  sequential  symbol 
hooking  without  pointer  movement,  a  user-defined  contact  list,  location  by  contact  name 
and/or  number,  and  sequential  switching. 

2.  Users  shall  be  able  to  hook  a  track  by  placing  the  pointer  over  the  symbol  and  performing 
a  select.  A  contact  that  is  hooked  shall  be  placed  in  the  visual  "foreground"  such  that  no 
other  contacts  obscure  it  or  partially  cover  it. 

3.  In  contact-rich  environments  it  is  not  always  possible  to  determine  which  of  the  objects  is 
hooked  if  the  sole  visual  indicator  on  the  tactical  display  is  a  graphic  (such  as  the  rounded 
shape  currently  used)  surrounding  the  contact.  The  capability  to  step  through  overlapping 
tracks  is  necessary,  but  not  sufficient.  An  auxiliary  visual  cue  (e.g.,  making  the  hooked 
contact  appear  brighter  for  a  period  after  it  is  hooked)  shall  be  implemented. 

4.  Contacts  shall  be  automatically  pre-selected  when  they  are  closest  to  the  pointer.  Pre¬ 
selection  provides  operator  specified  contact  information  in  the  pre-hook  window  and 
indicates  to  the  operator  which  object  will  be  hooked  if  the  operator  performs  a  select.  A 
white,  dotted  circle  shall  be  placed  around  contacts  when  they  are  pre-selected  unless  the 
contact  is  already  selected. 

5.  Users  shall  be  able  to  select  a  single  object  on  a  map  within  a  densely  packed  group  of 
objects.  When  a  graphical  item  is  selected,  it  shall  be  highlighted.  If  appropriate  to  the 
application,  users  may  reposition  selected  elements  on  the  display. 

6.  Symbols  other  than  contacts,  such  as  special  points  or  Identify  Friend/Foe  (IFF)  symbols, 
are  highlighted  in  the  same  manner  as  contacts. 

7.  Selected  lines  are  highlighted  by  changing  the  colour  and  thickness  of  the  line  and  any 
points  associated  with  the  line.  The  line  width  and  any  points  shall  be  increased  by  1.5-2 
times  their  normal  size. 

8.  Selected  areas  are  highlighted  by  placing  a  coloured  outline  around  the  entire  area  thus 
changing  the  colour  of  its  outlines  and  associated  points.  The  outline  width  and  any 
points  shall  be  increased  by  1.5-2  times  their  normal  size. 

9.  Primary  or  pre-selection  will  remove  whatever  information  is  currently  in  the  respective 
amplification  window  including  contact  information.  The  same  guidelines  apply  as  with 
contact  selection. 


Source 

CSFAB,  TBM,  D1SA,  R/SAOC. 

Discussion 


210 


DRDC  Toronto  TR  2009-062 


G4.  CFSAB  specifies  the  use  of  the  Advanced  Hooking  Algorithm  for  this  purpose.  A 
description  of  the  algorithm  can  be  found  in  Osga  [47], 

G9.  Secondary  selection  is  defined  to  permit  multiple  users  to  hook  objects  on  a  single 
display;  access  is  via  a  middle  input  device  button.  Secondary  selection  is  not  addressed  in  the 
Guide  and  is  not  referenced  here. 

21 .2.4.2  Contact  (or  object)  amplification  window 

1.  Amplifying  information  for  any  hooked  object  is  provided  via  the  same  amplification 
area  and  pop-up  windows  used  for  contact  information. 

2.  The  contact  amplification  window  shall  be  a  fixed  window. 

3.  The  system  shall  contain  a  contact  amplification  window  that  displays  the  object 
information.  The  operator  shall  be  able  to  select  what  amplification  information  is 
displayed. 

4.  A  contact  amplification  pop-up  window  shall  be  able  to  be  toggle  on  and  off  for  both 
hooked  and  pre-selected  contacts  through  their  respective  amplification  windows.  When 
the  pre-select  pop-up  window  is  on,  it  shall  be  displayed  when  the  object  is  pre-selected. 
The  hooked  pop-up  window  may  be  displayed  on  selection  as  determined  by  the  operator. 

5.  A  data  block  is  a  special  case  of  amplification.  A  data  block  shall  contain  basic 
information  about  a  hooked  object.  Data  blocks  are  used  to  provide  a  view  of  the 
essential  information  about  objects  on  the  display  without  requiring  that  the  operator  take 
eyes  off  of  the  tactical  picture  display. 

6.  If  data  blocks  are  implemented  they  shall  have  the  following  characteristics: 

■  The  data  block  information  shall  be  presented  on  a  transparent  background  so  as 
not  to  obscure  the  tactical  picture. 

■  The  display  of  data  blocks  shall  be  selectable  by  the  operator. 

■  The  data  block  shall  be  able  to  be  hooked  on  the  display  and  moved  to  another 
portion  of  the  tactical  display. 

■  The  data  block  shall  include  a  thin  line  connecting  the  data  block  to  the  object 
with  which  it  is  associated  if  the  data  block  has  been  re-located  by  the  operator. 

■  The  data  block  shall  move  with  the  associated  object  and  shall  keep  its  position 
relative  to  the  associated  object. 

■  Information  in  the  data  block  shall  be  presented  in  a  fixed  order  that  shall  be 
common  to  all  data  blocks  of  specific  types. 

■  Display  of  data  blocks  shall  be  operator-selectable. 

Source 

CSFAB,  UCA,  R/SAOC. 

Discussion 
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G5.  The  concept  of  data  blocks  is  used  successfully  in  a  number  of  systems  in  both  Air 
Defence  and  Air  Traffic  Control. 

21.2.4.3  Sequential  contact  hooking 

1.  The  user  shall  be  able  to  place  the  pointer  in  the  location  of  a  group  of  symbols  and 
successively  hook  each  symbol  in  a  specified  range  without  moving  the  pointer.  As  the 
user  presses  the  sequence  function,  the  next  symbol  in  the  group  shall  be  selected. 
Contacts  shall  be  sequenced  in  the  same  order  as  their  layering,  with  top  contacts  being 
sequenced  first. 

2.  A  symbol  that  is  currently  highlighted  in  the  symbol  list  shall  appear  in  the  visual 
foreground  on  the  tactical  map. 

3.  The  operator  shall  be  able  to  select  a  contact  by  entering  its  contact  number  or  selecting 
its  name  from  a  list  of  labelled  contacts.  The  contact  shall  be  highlighted  with  the 
selection  ring  and  the  selection  ring's  new  position  shall  be  identified  to  the  operator  by 
the  location  cursor  that  shall  disappear  after  2  seconds. 

4.  Sequential  switching  shall  be  able  to  be  toggled  off  and  on  by  the  user  with  the  default 
being  off.  If  any  contacts  are  overlapping,  the  contacts  are  sequentially  rotated  from  top 
to  bottom.  Contacts  shall  be  cycled  at  a  default  rate  of  2  Hz  and  this  rate  shall  be 
adjustable  by  the  user. 

5.  Upon  selection  of  a  new  object,  the  previously  selected  symbol  shall  be  released.  Primary 
selection  shall  release  the  primary  selected  object. 

6.  The  labels  on  dynamic  graphic  displays  shall  remain  with  the  top  of  the  label  up 
regardless  of  the  orientation  of  the  object. 

7.  The  user  shall  have  the  capability  to  obtain  exact  map  coordinates  of  selected  symbol  or 
map  features. 


Source 

CSFAB,  DISA,  MS1472F. 

Discussion 

Gl.  CSFAB  recommends  an  audible  cue  to  indicate  that  each  item  in  the  entire  stack  of 
overlapping  symbols  has  been  hooked  in  turn.  The  requirement  for  an  audible  alert  has  been 
removed. 

G.5  CSFAB  indicates  that  multiple  symbol  selection  is  permitted  but  is  not  the  default. 

21.2.4.4  Selecting  contacts  from  tables 

1 .  A  columnar  list  of  selectable  contacts  shall  present  a  symbol  graphic,  contact  descriptor 
text,  ID  number,  and  up  to  two  other  database  descriptors.  This  list  provides  quick  access 
to  the  most  important  contacts  in  the  plot.  A  maximum  of  nine  contacts  shall  be  permitted 
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in  this  list.  The  list  shall  be  sortable  by  column.  When  invoked,  the  list  shall  appear  in  a 
window  at  the  edge  of  the  tactical  situation  map.  The  user  shall  be  able  to  resize,  move, 
and  close  the  list. 

2.  The  selectable  contact  list  shall  contain  tracks  that  meet  one  of  several  user-determined 
Flag  Force  threat,  kinematic  or  descriptive  categories  such  as: 

■  all  within  a  specified  range 

■  hostile  surf/sub/air/all 

■  military  surf/sub/air/all 

■  targeted  surf/sub/air/all 

■  all  tracks  on  display  map 

■  user-selected  track  numbers  (sorted) 

■  surf/sub/air  contacts 

■  flag  force  threat  category  contacts 

■  other  track  descriptive  criteria 

Source 

CSFAB. 

21.2.5  Tactical  display  overlays  and  filters 

1.  An  automated  means  shall  be  provided  to  register  graphic  data  with  background  map 
information  at  all  display  scales. 

2.  Maps  shall  allow  situation  display  overlays  on  related  map  backgrounds.  Overlays  that 
obscure  data  shall  not  permanently  erase  any  data,  and  covered  data  is  automatically 
redrawn  if  the  covering  overlay  is  removed. 

3.  Map  labels  and  other  overlay  data  shall  be  positioned  consistently  (e.g.,  beneath  or  within 
the  feature)  and  all  significant  features  shall  be  labelled. 

4.  An  option  shall  be  provided  to  suppress  some  or  all  labels  on  a  map  display. 

5.  Map  overlays  such  as  country  or  city  names,  contact  names,  road,  rivers,  or  borders  shall 
be  able  to  be  toggled  on  or  off  by  the  operator  to  avoid  unnecessary  clutter.  The  operator 
shall  be  able  to  set  preferences  to  toggle  these  values  based  on  the  current  range  scale. 

6.  If  applicable,  elevation  features  are  represented  using  colour  shade  coding  of  a  single 
colour  range  (for  example  shades  of  blue  for  depth  of  water),  rather  than  hue  coding  (i.e., 
red,  yellow,  green,  etc.).  Terrain  features  identification  and  classification  and  operational 
data  may  use  hue  coding.  Colours  do  not  change  in  any  window  when  the  focus  is  shifted 
from  one  window  to  another. 

7.  Map  labels  shall  remain  legible  at  all  display  resolutions. 
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8.  Topographic  and  bathometric  data  shall  be  displayed  using  shading  of  the  land  and  water 
colours.  Darker  shades  shall  be  used  for  lower  elevations  and  lighter  shades  for  higher 
elevations. 

9.  Maps  or  situational  displays  shall  provide  a  user-selectable  grid  overlay  that  is  keyed  to 
the  coordinate  system  of  the  map. 

10.  The  intensity  of  the  map  and  overlays  shall  be  adjustable  to  fade  out  without  losing  all 
map  features,  while  maintaining  the  brightness  of  selected  overlays. 

1 1 .  If  appropriate  to  the  application,  map  backgrounds  with  user-selected  overlays  (situation 
displays)  may  be  named  for  ease  of  storage,  retrieval,  modification,  display  and  hard 
copy. 

12.  Filters  shall  be  provided  and  may  include  Category/ID  filters,  geographical  filters,  range 
and  vector  filters,  attribute  filters. 

13.  Essential  contacts  that  shall  not  be  filtered  out  of  the  display  include  the  following: 
hostile  tracks,  unknowns,  friendly  interceptors  or  fighters,  and  any  track  subject  to 
engagement  status. 


Source 

CSFAB,  TBM,  D1SA,  Handbook  5. 

21.2.6  Maps 

1.  The  curvature  of  the  earth  shall  be  consistently  projected  on  flat  surface  maps  when 
displaying  large  geographic  areas. 

2.  When  an  entire  map  is  not  displayed,  an  inset  may  be  displayed.  An  inset  shall  show 
where  the  displayed  portion  is  located  within  the  larger  map. 

3.  The  inset  map  shall  only  show  outline  features  such  as  political  boundaries,  shoreline, 
rivers,  lakes,  etc. 

4.  Maps  (for  example,  chart  inset  windows)  that  are  used  solely  during  the  performance  of  a 
task  shall  be  located  physically  near  the  window(s)  associated  with  the  task,  and  linked  to 
these  windows  with  respect  to  window  layering  on  the  display  as  a  child  window.  It  shall 
perform  in  the  same  fashion  as  other  child  windows. 

5.  When  more  than  one  map  will  be  displayed,  maps  of  the  same  projection  shall  be 
displayed  throughout  the  application  using  the  same  orientation. 

6.  All  maps  shall  be  oriented  such  that  north  is  always  facing  up  (north  at  the  top  of  the 
display). 

7.  A  map  window  shall  include  identifying  information  about  map  and  status  information. 
This  information  includes  map  name,  coordinates,  area,  and/or  scale  and  may  be 
displayed  on  the  map  or  in  a  separate  associated  window.  If  appropriate  to  the 
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application,  information  on  mapping  product  type,  mapping  media,  and  date  read,  and 
date  created  shall  be  provided. 

8.  Identifying/status  information  shall  appear  in  the  window  area,  along  the  bottom  window 
margin,  or  in  a  separate  dialog  window. 

9.  Underlying  geo-information  system  or  other  maps  placed  on  the  situation  display  shall 
not  interfere  with  the  primary  (contact  or  track)  information. 


Source 

CSFAB,  TBM,  D1SA,  MH761,  UCA. 

21.2.7  Tactical  display  control 

21.2.7.1  Map  control  characteristics 

1.  Map  controls  may  appear  in  the  map  window  or  are  available  in  separate  dialog  windows. 

2.  Map  controls  shall  be  commonly  located  in  a  horizontal  area  below  the  map  window. 

3.  The  user  shall  be  able  to  adjust  the  contrast  of  maps  and  overlays. 

4.  Users  shall  be  able  to  define  a  baseline  or  home  position  on  a  tactical  display  and  return 
to  this  position  quickly.  The  default  home  position  shall  be  Ownship. 


Source 

CSFAB,  TBM,  D1SA. 

Discussion 

G4.  The  requirement  was  edited  to  include  the  default  position;  the  default  is  consistent  with 
the  Flalifax-Class  CCS  and  with  the  Cognitive  Task  Analysis  of  the  Flalifax-Class  ORO  [48]. 

21.2.7.2  Panning  and  zooming 

1 .  The  range  scale  shall  be  able  to  be  increased  or  decreased  between  a  continuous  range  of 
values  not  just  set  increments.  Pre-set  range  options  shall  be  provided  for  quick  access. 

2.  The  base  set  of  ranges  for  the  operators  shall  at  minimum  be  as  follows: 

i.  ORO  requires  2  to  256  nm 

ii.  SWC  requires  8  to  256  nm 

iii.  AS WC  requires  2  to  32  nm 

3.  A  map  shall  permit  the  user  to  change  the  displayed  area  by  panning  or  moving  a  window 
over  the  map  in  any  direction. 


DRDC  Toronto  TR  2009-062 


215 


4.  During  a  panning  operation,  map  windows  shall  provide  an  indicator  position  in  the 
overall  map  window. 

5.  During  a  panning  operation,  the  user  shall  be  provided  with  the  capability  to  rapidly 
return  to  a  starting  point. 

6.  A  map  shall  provide  a  means  for  moving  away  from  or  toward  the  displayed  area 
(zooming)  to  obtain  a  larger  view  or  greater  detail. 

7.  Provide  one-button  access  to  a  set  of  pre-set  zoom  levels. 

8.  Operators  shall  be  able  to  quickly  zoom  a  map  as  desired. 

9.  Operators  shall  be  able  to  zoom  by  either  selecting  zoom  in  or  zoom  out  functions  that 
step  through  standard  scales  or  by  using  a  zoom  scale  widget. 

10.  Operators  shall  also  be  able  to  zoom  a  specific  map  area  by  selecting  that  area  with  the 
pointer  control  device.  Panning  shall  be  able  to  be  done  through  a  pan  widget. 

1 1 .  When  a  map  is  zoomed,  the  size  of  symbols,  labels,  and  other  map  features  shall  be 
adjusted  so  they  remain  the  same  readable  size  (i.e.,  symbol  size  does  not  change).  When 
zooming,  certain  objects  shall  be  collapsed  or  removed  depending  on  the  range  scale 
(e.g.,  City  names  are  displayed  if  the  range  is  less  than  100  miles).  This  will  avoid  clutter 
as  the  operator  zooms  into  a  larger  region.  The  range  criteria  to  collapse  or  remove 
objects  shall  be  adjustable  by  the  operator  and  contain  set  defaults. 

12.  If  a  zoomed  region  is  displayed  simultaneously  with  its  respective  larger  scale  map,  the 
zoomed  area  shall  be  depicted  on  the  parent  map  by  a  coloured  outline.  The  zoomed  map 
window  border  shall  be  the  same  colour  as  the  outlined  region. 

13.  When  changing  map  scales  through  zooming,  a  map  window  shall  provide  an  indicator 
that  continually  shows  the  appropriate  scale. 

14.  Area  of  the  picture  must  be  sufficient  to  cover  the  entire  area  of  interest.  Zoom  values 
must  be  appropriate  to  the  size  of  the  area  of  interest  and  other  sub-areas. 

15.  A  map  or  other  graphic  display  shall  provide  an  indicator  of  the  scale  expansion. 

Source 

CSFAB,  TBM,  DISA,  UCA. 

Discussion 

G2.  These  values  were  obtained  via  interview  with  a  small  population  of  operators.  The 
values  should  be  validated  before  implementing  the  range  scales. 

G7.  Although  DISA  suggests  that  continuous  zooming  operations  are  preferred  over  discrete 
operations,  operators  benefit  from  direct  and  immediate  access  to  a  relevant  set  of  discrete  zoom 
levels. 
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G12.  This  will  allow  for  multiple  areas  to  be  zoomed  simultaneously  and  for  the  operator  to  be 
able  to  see  where  these  areas  are  located  in  the  original  map. 

G15.  MS1472F  specifies  that  the  indicator  shall  be  shown  when  the  display  is  expanded. 

21.2.7.3  Tactical  display  re-play 

1.  When  users  play  back  a  situation  display,  they  shall  be  permitted  to  set  the  overall 
playback  rate,  stop  the  playback,  start  the  playback,  step  quickly  forward  through  the 
playback  (fast  forward),  and  step  quickly  backward  through  the  playback  (reverse). 

2.  Video,  audio  or  similar  playback  controls  shall  be  enhanced  with  text  labels  for  each 
control. 
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Source 


MH761,  UCA. 

Discussion 

G2.  Standard  video  and  playback  controls  are  recommended  by  MH761.  Because  these  are 
frequently  misinterpreted  by  users  (even  though  they  are  a  standard  throughout  a  range  of 
industries)  the  video,  audio  or  similar  playback  controls  need  to  be  enhanced  with  text  labels  for 
each  control. 

21 .2.8  Symbology  (map  or  tactical) 

1.  The  symbology  applicable  to  the  CCS  shall  be  consistent  with  the  NTDS,  or  other 
conventions  as  specified.  The  plotting  symbols  are  presented  in  Table  9-1A  through  C: 
Plotting  Symbols  in  NOSTP.  The  most  recent  NOSTP  document  shall  be  used  as 
reference. 

2.  Map  symbols  shall  not  overlap.  Where  overlapping  symbols  are  unavoidable  a  means 
shall  be  provided  for  moving  background  symbols  to  the  foreground  or  otherwise 
revealing  masked  symbols. 

3.  Any  object  on  the  map  display  may  be  selectable  as  required  by  the  system.  Selectable 
objects  other  than  symbols  include:  route  segments,  waypoints,  tactical  areas,  countries, 
etc. 

4.  Selected  points  shall  be  highlighted  by  changing  the  colour  of  the  point  and  enlarging  it 
to  1.5  times  its  normal  size. 

5.  Overlapping  of  symbols  and  tracks  is  allowed  but  total  obstruction  of  any  contact  is 
prohibited.  At  least  25%  of  the  total  area  of  a  contact  shall  be  visible  at  all  times.  This  can 
be  done  by  offsetting  the  location  of  the  contact  symbol.  The  symbol  location  of  the 
lower  priority  contact  shall  be  offset.  When  an  offset  contact  is  selected,  it  shall  be 
repositioned  in  its  true  location. 

6.  Symbols  shall  be  overlapped  with  more  important  symbols  being  placed  on  top.  The 
system  shall  default  to  the  following  threat  prioritization  from  top  to  bottom:  hostiles, 
unknowns,  friends,  and  neutrals. 

7.  Priority  will  be  given  to  air,  subsurface,  then  surface  contacts.  However,  the  user  shall  be 
able  to  change  the  prioritization  of  contacts.  Tools  shall  be  provided  to  allow  the  operator 
to  view  and  access  layered  contacts. 

8.  When  multiple  objects  are  plotted  over  the  map,  the  following  layering  conventions  shall 
be  followed  (layered  from  the  foreground  or  top  to  the  background  or  bottom): 

i.  pop-up  dialog  menus 

ii.  waypoints 

iii.  route  segments 
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iv.  engagement  symbol  modifiers 

v.  symbols 

vi.  hooked  and  pre-selected  contacts 

vii.  weapon  (missile,  etc.) 

viii.  hostile 

ix.  suspect 

x.  unknown 

xi.  assumed  friend 

xii.  friend 

xiii.  neutral 

xiv.  IFF  (at  the  same  level  as  its  associated  contact) 

xv.  special  points 

xvi.  tactical  graphics 

xvii.  range  rings 

xviii.  air  routes 

xix.  weather 

xx.  environmental  data 

xxi.  radar  returns 

xxii.  maps 

xxiii.  borders 

xxiv.  water 

xxv.  land 

9.  The  operators  shall  be  able  to  select  the  option  to  display  labels  for  selected  symbols. 

10.  The  operator  shall  be  able  to  select  an  overlay  of  specific  contacts  or  groups  of  contacts 
that  share  common  characteristics. 

11.  Map  symbols  shall  be  placed  accurately  on  a  map  or  connect  to  the  desired  location  using 
arrows,  lines,  or  other  graphic  pointing  methods. 


DRDC  Toronto  TR  2009-062 


219 


12.  Track  numbers  shall  be  displayed  with  both  of  the  two  most  recent  track  numbers  when 
track  numbers  are  updated  frequently. 


Source 

CSFAB,  TBM,  D1SA,  UCA,  NOSTP. 

Discussion 

G8.  TBM  prioritizes  the  contacts  as  air,  subsurface,  then  surface  contacts.  The  prioritization 

and  layering  order  should  be  validated  by  users  before  implementing. 

G9.  The  layering  conventions  should  be  validated  by  the  users  and  be  consistent  with 

available  task  analysis  data  before  implementing. 

21.2.9  Tactical  graphics 

1.  Tactical  graphics  allow  operators  to  define  meaningful  areas  such  as  fly  zones, 
operational  areas,  waypoints,  etc.  that  are  not  visually  distinguished  by  the  mapping 
software.  Tactical  graphics  shall  be  attachable  to  map  objects  or  specific  map 
coordinates. 

2.  The  operator  shall  be  provided  tools  for  placing  tactical  graphics  on  a  map.  As  a 
minimum  the  operator  shall  be  able  to  define  rectangles  by  entering  two  latitude  and 
longitude  sets  and  define  circles  by  entering  the  centre  latitude  and  longitude  and  the 
radius.  The  operator  shall  also  be  able  to  define  asymmetric  regions  or  lines  by  entering  a 
series  of  latitudes  and  longitudes  in  a  connect-the-dots  fashion.  If  an  area  is  being  drawn, 
the  final  segment  shall  be  a  connection  from  the  last  point  to  the  first  point.  Graphics  that 
are  centred  on  a  map  object  shall  use  the  object's  location  as  an  initialization  point. 

3.  Where  graphic  data  entry  involves  frequent  pointing  on  a  display  surface,  the  user 
interface  shall  provide  display  control  and  sequence  control  by  pointing,  in  order  to 
minimize  shifts  from  one  entry  device  to  another.  For  example,  in  drawing  a  flow  chart,  a 
user  shall  be  able  to  link  elements  or  points  directly  by  pointing  at  them  or  drawing  lines 
between  rather  than  by  separately  keyed  entries. 

4.  A  maximum  of  six  colours  may  be  used  to  display  tactical  graphics.  Designers  and  users 
shall  include  the  following  guidelines  when  selecting  colours  for  tactical  graphics  (unless 
superseded  by  explicitly  specified  symbology  conventions). 

■  Rust  =  areas  friendlies  should  avoid 

■  Teal  =  areas  friendlies  should  be  located  or  hostiles  should  not 

■  Gold  =  areas  no  contact  should  be  located  or  areas  friendlies  may  have  to  go  but 
will  be  in  increased  danger 

■  Green  =  commercial  or  neutral  areas 

■  Purple/Magenta  =  areas  of  no  threat  significance,  reserved  for  use  by  the 
designer  and  users  at  their  discretion 
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5.  Tactical  graphics  associated  with  a  contact  shall  take  on  the  colour  family  of  that  contact 
as  in  the  examples  below  unless  superseded  by  explicitly  specified  symbology 
conventions  (see  also  [19]): 

■  Red  =  Rust 

■  Cyan  =  Teal 

■  Yellow  =  Gold 

■  Green  =  Green 

6.  Fill  patterns  are  based  on  the  layering  and  size  of  the  tactical  graphics.  Large  areas  shall 
have  less  dense  fill  patterns  so  as  to  not  overpower  other  objects  on  the  display.  As  the 
default  the  system  shall  use  the  1/16  dot  fill  pattern.  If  a  graphic  is  placed  on  top  of 
another  graphic  it  shall  receive  the  next  denser  level  of  fill  pattern.  Graphical  areas 
located  completely  inside  another  graphical  area  shall  be  place  on  top  of  that  area. 

7.  Tactical  graphics  shall  be  global,  shared,  or  personal.  Global  means  all  displays  will 
contain  these  graphics  until  removed  by  the  operator.  Shared  allows  other  operators  to 
access  a  graphic  someone  else  has  defined.  Personal  means  only  the  originator  of  the 
graphic  can  display  that  object. 

8.  Users  shall  be  able  to  create  personal  objects,  add  shared  objects,  and  shall  automatically 
receive  global  objects.  Operators  shall  have  the  option  to  automatically  include  shared 
objects  developed  by  authorized  users  (e.g.,  the  combat  officer  may  wish  to  automatically 
add  all  shared  graphics  developed  by  the  team).  Users  shall  be  able  to  edit,  reposition, 
and  delete  personal  items.  Shared  and  global  items  can  only  be  toggled  on  and  off  by  all 
operators.  Shared  and  global  items  may  be  altered  but  are  required  to  be  saved  as  a  new 
object  unless  the  operator  is  the  originator  or  has  authorization  to  make  changes. 

9.  Any  tactical  graphic  may  be  attached  to  a  map  object,  like  a  symbol,  track  or  another 
tactical  graphic.  By  attaching  a  graphic,  the  graphic  follows  that  object  wherever  if  goes. 
Attached  graphics  shall  be  generated  by  selecting  the  object  and  issuing  an  “attach 
graphic”  command.  A  new  graphic  may  then  be  developed  or  an  existing  graphic  may  be 
attached.  The  graphic  shall  be  centred  on  the  contact  as  a  default  but  this  option  may  be 
toggled  off  by  the  operator. 

10.  The  operator  shall  have  the  ability  to  toggle  on  and  off  information  (e.g.,  speed  leaders, 
IFF  symbols,  track  history,  and  tactical  overlays)  to  display  only  the  information  useful  to 
the  task. 

1 1 .  IFF  symbols  shall  always  be  oriented  vertically. 

12.  The  size  of  IFF  symbols  shall  be  selectable  between  two  sizes.  The  same  sizes  shall  be 
used  for  associated  alphanumeric  symbols  with  a  height/width  ratio  of  1:1  to  obtain 
maximum  legibility  of  capital  letters. 

13.  Use  the  IFF  symbol's  centre  as  its  exact  location  on  the  tactical  display.  This  point  shall 
be  offset  from  the  associated  contact  symbol  or  radar  return.  The  offset  shall  be  on  a 
bearing  line  from  own  ship  to  the  associated  track  or  radar  return  and  shall  be  beyond  the 
associated  track  or  radar  return  by  a  standard  number  of  pixels  that  is  adjustable  by  the 
operator. 
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14.  Colour  recommendations  for  IFF  symbols  are  based  on  task  requirements.  Provide  the 
operator  with  an  option  of  four  colour,  two  colour,  or  monochrome  (off-white  or  white) 
IFF  symbols.  Provide  a  one  pixel,  black  outline  around  each  symbol  so  it  does  not  lose  it 
shape  in  a  cluttered  environment.  In  a  two  colour  mode  the  colour  magenta  is  used  for  the 
Passive  Decode,  I/P,  Mode  4,  and  emergency  symbols.  The  remaining  IFF  symbols  are 
coloured  off-white  or  white. 

15.  Alphanumeric  coding  shall  be  used  to  denote  passive  decodes.  Flowever,  do  NOT  use 
“A”,  “V”,  “O”,  “Q”,  or  “U”  as  they  may  be  mistaken  for  outline  contact  symbols. 
Confusion  may  occur  between  “A”  and  hostile  air  contacts,  “V”  and  hostile  subsurface 
contacts,  “O”  or  “Q”  and  friendly  surface  contacts,  and  “U”  and  friendly  subsurface 
contacts. 


Source 

CSFAB. 

Discussion 

G14.  A  four-colour  scheme  for  IFF  symbols  introduces  undue  complexity  into  the  ORO,  SWC, 
and  ASWC  displays  and  so  is  not  included  here. 

21.2.10  Uncertainty 

1.  Contact  uncertainty  may  be  displayed  to  show  the  operator  the  system’s  confidence  in  the 
contact  information.  The  range  of  uncertainty  may  be  displayed  as  the  maximum  and 
minimum  or  within  a  certain  confidence  interval.  The  most  effective  uncertainly  displays 
are  intuitive. 

2.  Graphics  conveying  uncertainty  shall  use  fuller  (or  larger)  symbols  to  represent  higher 
levels  of  certainty;  less  full  (or  smaller)  symbols  shall  be  used  to  represent  less  certainty. 

3.  Display  of  uncertainty  shall  be  consistent  with  the  recommendations  resulting  from  the 
most  current  applicable  research. 
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Source 


CSFAB,  UCA. 

Discussion 

Gl.  Before  implementing  an  aid  of  this  nature,  its  operational  effectiveness  should  be 
validated.  Some  attempts  to  assist  the  operators  by  displaying  the  level  of  uncertainty  add  clutter 
without  substantially  aiding  the  operator. 

G2.  This  guideline  is  based  on  the  results  from  a  Symbology  and  Design  Study  conducted 
under  the  COMDAT  TDP  [49].  In  that  study,  it  was  determined  that  operators  who  participated  in 
the  study  viewed  larger  symbols  or  fuller  symbols  as  representing  MORE  certainty.  While  larger 
objects  are  generally  perceived  as  more  important  than  smaller  objects,  there  appears  to  be  a 
conflict  between  representations  of  certainty  and  importance.  It  is  recommended  that  increased 
size  in  symbols  be  reserved  to  draw  attention  to  important  information  (such  as  errors  or 
dangerously  low  ammunition  reserves)  rather  than  to  convey  certainty.  For  displays  of  certainty, 
larger  symbols  are  intuitively  interpreted  as  conveying  more  certainty  and  newly  developed 
symbology  should  be  consistent  with  the  operators’  intuitive  mental  models. 

G3.  The  original  CFSAB  guidelines  included  specific  recommendations  for  representing 
location  and  bearing  uncertainty.  Since  the  basis  for  those  recommendations  was  not  clear,  it  was 
decided  not  to  include  them.  Examples  of  uncertainty  symbols  that  have  been  tested  using  CF 
personnel  can  be  found  in  [49]  and  [50], 

21.2.11  Saving  preferences 

1.  Operators  shall  be  provided  the  ability  to  set  map  preferences  to  that  of  any  saved  map. 
Saved  maps  can  be  any  map  configuration  that  is  saved  by  an  operator  under  a  given  title. 
Only  map  view,  map  detail,  tactical  graphic,  and  special  point  information  are  stored  for  a 
saved  map.  Track  and  radar  appearance  are  always  specific  to  the  situation  and  the 
operator’s  workstation. 

2.  If  information  will  be  lost  by  changing  from  one  map  to  another,  the  operator  shall  be 
given  the  option  to  retain  that  additional  information.  Operators  shall  have  quick  access 
to  a  series  of  selected  saved  maps  to  provide  commonality  at  the  appropriate  command 
levels.  These  are  the  group,  ship,  team,  and  personal  maps.  If  an  operator  resaves  a  map, 
its  new  preferences  shall  only  be  seen  by  others  using  that  map  if  they  re-select  the  map. 

3.  A  standard  set  of  default  map  preferences  will  be  used  for  the  personnel,  team,  and  ship 
maps  until  they  are  defined.  The  default  map  is  a  global  default  for  all  operator  positions 
in  a  defined  group.  Only  specified  users  may  alter  the  preferences  of  a  default  map. 

4.  The  group  commander  will  be  able  to  select  any  saved  map  as  the  group  map  for  all  those 
under  his/her  command.  Only  specified  users  may  alter  the  preferences  of  a  group  map. 

5.  The  combat  system  commander  will  be  able  to  select  any  saved  map  as  the  ship  map  for 
all  those  under  his/her  command.  Only  specified  users  may  alter  the  preferences  of  a  ship 
map. 
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6.  Team  leaders  will  be  able  to  select  any  saved  map  as  a  team  map  for  those  under  his/her 
command.  Only  specified  users  may  alter  the  preferences  of  a  team  map. 

7.  All  operators  shall  have  the  ability  to  select  any  saved  map  as  their  personal  map 
including  other  personal  maps.  Choosing  a  saved  map  as  a  personal  map  resaves  that 
map’s  preferences  under  a  personal  file.  This  avoids  personal  maps  being  altered  if 
changes  are  made  to  a  saved  map. 

8.  If  maps  and/or  situation  displays  are  stored,  or  if  more  than  one  map  and/or  situation 
display  appears  in  an  application,  an  index  shall  be  available. 


Source 

CSFAB,  TBM. 


21.3  Tactical  pop-ups 

1.  The  pop-up  menu  shall  contain  functions  most  commonly  used  with  the  related  object. 
The  map  pop-up  window  will  be  the  default  pop-up  menu  if  no  other  object  is  under  the 
pointer. 


2.  Each  pop-up  menu  shall  be  organized  in  three  sections  as  follows: 

■  Top  Section- Action 

■  Middle  Section-Display  Attributes,  Specific 

■  Bottom  Section-Display  Attributes,  Global 

3.  The  following  organization  of  pop-up  menu  contents  shall  be  used  whenever  the  contents 
are  applicable: 

■  Map  Controls  Pop-Up 

♦  Zoom  In 

♦  Zoom  Out 

♦  Zoom  Box 

♦  Pan 

♦  Centre  Map 

♦  Borders 

♦  Detail 

♦  Topography 

♦  Colours 

■  Radar  Pop-Up 

♦  Radars  Available 

♦  Returns 

♦  Fade 
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♦  Sweep 

♦  Appearance 

♦  On/Off 

■  Tactical  Graphic  Pop-Up 

♦  Coordinates 

♦  Info/Label 

♦  Appearance 

♦  Sharing 

♦  Remove 

■  Segment/Waypoint  Pop-Up 

♦  Coordinates 

♦  Info/Label 

♦  Remove 

■  IFF  Pop-Up 

♦  Mode  4  Interrogate 

♦  Stretch 

♦  Size 

♦  Colours 

♦  Offset 

♦  On/Off 

■  Contact  Pop-up 

♦  Engage 

♦  Drop 

♦  Interrogate 

♦  Communicate 

♦  Info/Label 

♦  Prominence 

♦  Uncertainty 

♦  Speed  Leaders 

♦  Appearance 

♦  Symbol 

♦  Flistory  Points 

♦  Range  Circles 

♦  Dead  Reckon  (DR) 
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♦  DR  Trailer 

♦  Other 

4.  Pop-up  menus  sorted  by  contacts  within  a  user-specified  range  of  the  pointer  shall  be 
available  to  aid  in  contact  selection  from  a  group.  If  the  sorted  pop-up  menu  capability  is 
required  it  shall  be  implemented  as  follows: 

■  The  default  range  shall  be  a  radius  of  1/20  the  shortest  tactical  display  dimension 
(If  the  tactical  display  is  12"  by  10",  the  range  would  be  a  radius  of  10"  x  1/20 
=0.5"  around  the  pointer). 

■  Display  of  the  pop-up  menu  shall  be  user-invoked  by  holding  the  select  button 
for  a  user-specified  period.  The  default  time  shall  be  0.5  seconds. 

■  Upon  activation,  a  circle  of  the  specified  range  shall  be  displayed  around  the 
pointer  along  with  the  pop-up  menu. 

■  The  pop-up  menu  shall  be  displayed  in  the  immediate  vicinity  of  the  pointer 
without  overlapping  the  range  circle. 

■  The  pop-up  menu  shall  show  a  columnar  listing  including  all  contacts  in  the 
specified  range  and  allow  user  selection  of  contacts  from  the  menu. 

■  Each  row  on  the  menu  shall  contain  the  symbol  contact  ID  number,  a  graphic 
picture  of  the  symbol,  and  a  short  noun  descriptor  e.g.,  tanker,  or  other 
information  appropriate  to  Canadian  C2. 

■  Selecting  a  contact  in  the  menu  shall  also  select  that  contact  on  the  display  and 
bring  it  to  the  foreground. 

Source 

CSFAB,  UCA. 

Discussion 

Before  implementing  tactical  pop-up  menus  the  tactical  benefit  of  each  pop-up  and  each  item  in 

the  pop-up  should  be  validated  for  Canadian  Maritime  operations. 
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Evaluation  methods  and  measures 


Design  verification: 

•  Verification  of  visibility  of  information,  ease  of  use,  and  design  consistency  of  all  maps  and 
situation  displays  and  associated  controls  and  tools. 

•  Operator  performance: 

•  Objective  assessment  of  use  and  usefulness  of  all  maps  and  situation  displays  and  associated 
controls  through  usability. 

•  Objective  assessment  of  speed  and  accuracy  of  detection  and  recognition  of  critical  objects 
and  information  on  maps  and  situation  displays. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  perceptions  of  usability  and  utility 
of  maps  and  situation  displays  and  associated  controls  and  tools. 

•  Assessment  of  the  intuitiveness  of  uncertainty  representations  and  symbolic  information  in 
the  OMI. 

Operator  decision  making  quality: 

•  Assessment  of  timeliness  and  agility  of  decision  making  using  scenario-based  studies. 

•  Assessment  of  situation  assessment  capabilities  using  scenario-based  studies. 

Operator  situation  awareness: 

•  Subjective  assessment  of  the  adequacy  of  the  operator’s  situation  awareness  of  the 
recognized  maritime  picture. 
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22  Colour 


22.1  Overview 

Colours  are  used  to  convey  specific  information.  The  use  of  colour  coding  should  be  kept  to  a 
minimum.  The  use  of  too  many  colour  codes  will  reduce  the  likelihood  that  significant  colour 
coding  will  be  interpreted  quickly  and  accurately  by  users.  Colour  is  only  an  effective  coding 
scheme  when  an  object  has  eight  or  less  possible  states.  Colour  is  most  advantageous  when  an 
operator  must  segregate  or  search  for  objects  in  a  cluttered  and  unformatted  display,  like  finding 
enemy  contacts  in  a  tactical  plot. 

Colours  must  be  evaluated  in  the  complete  context  of  the  display;  colours  are  subject  to 
perceptual  shifts  in  appearance  depending  on  their  context.  Perception  of  colour  also  changes 
depending  upon  lighting  conditions. 

Two  conditions  of  ambient  lighting  are  used  in  the  Halifax-Class  control  room.  These  lighting 
conditions  are  the  following: 

•  Normal  operations  room  lighting  (dim  lighting) 

•  Dark  adaptation  conditions  (red  lighting) 

To  maintain  dark  adaptation  red  lighting  is  used.  In  future,  other  colours  of  light  may  be  used 
instead  of  red  to  maintain  dark  adaptation  (e.g.,  blue)  and  other  ambient  lighting  may  be  used  for 
normal  operations  room  lighting  (e.g.,  daylight  or  office  lighting).  The  OM1  should  be  developed 
to  include  sets  of  colours  for  each  of  the  lighting  conditions  in  the  operations  room.  The  operators 
will  then  be  able  to  choose  the  optimum  display  for  the  appropriate  set  for  the  conditions. 

This  section  includes  colour  guidance  for  the  windows  colours  and  the  tactical  display  graphics. 
See  Section  21.1:  Radar  for  guidance  on  colour  display  of  raw  radar. 

22.2  Colour  sets 

1.  Colour  coding  for  the  windows  and  tactical  display  shall  follow  the  guidance  presented  in 
[51]  when  ambient  lighting  is  between  7-200  (20-300)  lux.  These  colours  were  chosen  to 
minimize  operator  eyestrain  that  can  occur  when  viewing  a  monitor  that  is  much  brighter 
than  the  environment. 

2.  If  ambient  room  lighting  is  above  300  lux  then  a  light  colour  scheme  shall  be  used. 

3.  In  a  dark  adaptation  environment,  a  dark  colour  set  (see  [51])  shall  be  tailored  for 
optimized  usability  under  the  specific  lighting  conditions. 

4.  Users  shall  be  able  to  select  between  colour  sets:  One  set  shall  be  provided  for  each  of  the 
lighting  conditions  in  the  operations  room  (e.g.,  normal  operations  room  lighting  and  dark 
adaptation  lighting). 

5.  The  operator  shall  have  the  options  to  select  between  colour  sets  for  each  applicable 
lighting  condition  but  shall  not  otherwise  adjust  the  individual  colours  in  the  display. 
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6.  The  colour  sets  for  the  displays  must  be  unambiguous  and  retain  cognitively  consistent 
colour  coding  conventions  under  all  lighting  conditions. 

7.  Changing  to  an  alternate  colour  set  shall  not  alter  security  classification  colours. 

8.  In  dim  environments  (most  operations  rooms,  ship’s  bridge  at  night,  submarines),  a  dark 
background  is  better  for  maintaining  proper  contrast  ratios  between  the  screen  and  the 
room  objects. 

9.  If  users  must  look  back  and  forth  between  monitors,  papers,  status  boards,  windows,  etc., 
the  contrast  ratio  between  any  of  these  objects  and  the  monitor’s  average  luminance  shall 
not  exceed  40: 1  with  a  preferred  value  of  20: 1 . 


Source 

CSFAB,  TBM,  MSWUE,  UCA,  HFDATC. 

Discussion 

Gl.  It  shall  be  noted  that  such  dark  environments  are  not  optimal  for  the  viewing  of  colours, 
reading  of  printed  documents,  or  face-to-face  communications.  Given  that  all  of  these  activities 
commonly  occur  in  Operations  Rooms,  an  ambient  lighting  level  of  100-500  lux  is  recommended. 

G3.  S52,  Appendix  2,  Specifications  for  chart  content  and  display  aspect  of  ECDIS, 

[51]  includes  colour  sets  for  all  levels  of  ambient  illumination.  The  night  set  is  designed 
to  preserve  dark  adaptation. 

G5.  TBM  permits  more  colour  customization. 

G6.  A  small  number  of  selectable  colour  sets  has  been  used  successfully  by  the  Icelandic 
Civil  Aviation  Authority  and  for  Electronic  Chart  Display  Information  System  (ECDIS)  [51]. 

22.3  Specific  colour  use 

1.  Colour  pairs  at  spectral  extremes  (e.g.,  red/green,  yellow/purple)  shall  not  be  used 
together  because  they  appear  to  vibrate  when  placed  next  to  each  other. 

2.  Pure  white  text  shall  not  be  displayed  on  a  pure  black  background  because  this 
combination  produces  an  effect  known  as  halation,  which  makes  text  less  readable. 

3.  Because  the  human  eye  has  difficulty  focusing  on  blue,  very  saturated  or  pure  shades  of 
blue  shall  not  be  used  for  text  or  for  any  critical  information. 

4.  Red  shall  be  used  to  indicate  critical  or  irreversible  options. 

5.  Red  shall  be  used  to  alert  the  operator  that  an  application/process  is  inoperative  until 
corrective  action  is  taken. 

6.  Yellow  codes  shall  be  used  only  to  alert  to  situations  involving  caution,  recheck,  or 
unexpected  delay. 
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7.  Black  shall  not  be  used  as  the  background  for  colour-coded  items. 

8.  Background  colours  shall  be  unsaturated  hues  (e.g.,  tan,  off-white)  and  shall  not  be  pure 
white. 

9.  Symbology  shall  be  colour  coded  using  the  following  conventions,  unless  superseded  by 
NTDS  [19]  or  other  explicitly  specified  symbology  conventions: 

■  hostile:  red  (or  magenta) 

■  friend:  blue  (or  cyan) 

■  unknown:  yellow 

■  neutral:  green 

10.  The  Halifax  Class  CCS  specifies  white  symbology  to  denote  computer-identified 
contacts.  The  CCS  specification  shall  be  followed  unless  superseded  by  specified 
symbology  conventions. 

1 1 .  Areas  are  highlighted  in  different  manners  when  hooked  depending  on  the  shape  of  the 
object.  The  distinction  between  primary,  secondary,  or  pre-selected  objects  shall  be  made 
by  the  highlight  colour. 


Source 

CSFAB,  TBM,  D1SA,  UCA. 

Discussion 

G10.  The  specification  for  white  symbols  in  the  Halifax-Class  CCS  should  be  verified. 

22.4  Colour  guidelines 

1.  Colour  shall  be  used  only  when  it  will  increase  operator  performance  or  situational 
awareness. 

2.  Borders  between  different  land  types,  water,  and  coastal  borders  shall  be  consistent  with 
the  conventions  presented  in  [51]. 

3.  A  maximum  of  three  land  and  three  water  colours  shall  be  used.  Exceptions  may  include 
topographic  and  bathometric  data  if  appropriate  shading  does  not  negatively  impact 
operations. 

4.  The  number  of  colours  used  to  code  the  information  for  graphical  displays  shall  not 
exceed  nine  since  users  have  difficulty  discriminating  among  more  than  this  number  of 
colours. 

5.  The  number  of  colours  used  to  code  the  information  for  alphanumeric  display  shall  not 
exceed  seven,  and  only  four  codes  shall  be  displayed  at  any  one  time. 

6.  Colour  shall  be  used  for  coding,  to  highlight,  aid  in  grouping,  or  to  clarify  relationships. 
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7.  When  colour  is  used  to  enhance  action  icons,  the  colours  shall  be  consistent  with 
Microsoft  Windows  conventions. 

8.  Colour  coding  may  be  employed  to  differentiate  between  classes  of  information  in 
complex,  dense,  or  critical  displays. 

9.  Colour  shall  be  used  consistently  within  an  application  and  between  applications  in  a 
system. 

10.  Colours  used  for  displaying  status  shall  be  the  same  throughout  the  application  and 
restricted  to  that  function. 

11.  Colour  used  in  predefined  message  windows  shall  only  be  used  in  the  symbol/icon  and 
shall  not  be  used  for  text. 

12.  If  colour  is  used  to  convey  meaning,  it  shall  be  used  redundantly  and  shall  not  be  the  only 
coding  technique. 

13.  If  colour  coding  is  used,  each  colour  shall  represent  one  category  of  displayed  data. 

14.  If  the  operator  must  focus  on  different  types  of  objects  in  the  display  for  different  tasks, 
the  operator  shall  be  given  the  ability  to  use  variable  coded  symbology  (e.g.,  only  colour 
code  contact  symbols  or  only  colour  code  IFF  symbols). 

15.  Slight  shade  changes  in  colour  shall  not  be  used  to  show  gradation  or  choice.  Exceptions 
may  include  topographic  and  bathometric  data  if  appropriate  for  operations. 

16.  The  background  colour  behind  the  text  shall  not  be  used  to  show  a  change  in  the  system 
status.  This  is  because  changing  the  background  colour  usually  reduces  the  readability  of 
the  text.  Instead,  change  in  system  status  shall  be  identified  by  changing  the  colour  of  an 
object  next  to  the  text. 

17.  Colour  code  customization  shall  be  only  permitted  for  information  that  is  not  tactically 
significant. 

18.  Unobtrusive  colours  shall  be  used  to  display  information  used  infrequently.  Warm 
colours  (those  with  longer  wavelengths,  such  as  red  or  orange)  shall  be  used  to  convey 
action  or  the  requirement  for  a  response. 

19.  Cool  colours  (those  with  shorter  wavelengths,  such  as  blue  or  green)  shall  be  used  to 
convey  status  or  background  information. 

20.  Wavelengths  above  650  nm  shall  be  avoided  if  the  operators  include  protanopes. 

Source 

CSFAB,  TBM,  DISA,  MS1472F,  MSWUE. 

Evaluation  methods  and  measures 

Design  verification: 
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•  Verification  of  consistency  of  use  and  reproduction  and  visibility  of  luminance  and 
chromaticity  of  all  colours  used  on  the  display. 

Operator  performance: 

•  Assessment  of  the  visibility,  discriminability,  and  recognition  of  all  colours  used  in  the 
OMI. 

Operator  acceptance: 

•  Assessment  of  the  intuitiveness  of  colour  coding  used  in  the  OMI. 
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23  Design  and  evaluation 


23.1  Adopt  operator-centered  design  principles 

1.  The  design  of  an  ESS  shall  begin  by  choosing  the  human-centered  criteria  (goals)  of  the 
system  and  then  defining  the  functions  that  the  system  will  perform. 

2.  Standard  operating  procedures  and  company  policies  shall  guide  system  designers  in  the 
appropriate  allocation  of  a  task  to  the  operator  or  the  ESS,  although  the  operator  shall  be 
ultimately  responsible  to  make  the  decision  to  use  or  not  use  the  automation. 

3.  A  substantial  proportion  of  the  operators  shall  be  involved  in  the  design  of  the  ESS. 

4.  The  ESS  shall  be  based  on  operator  population  characteristics  (cognitive  and  heuristic 
biases,  skills,  experience,  and  training)  and  cognitive  processes  (mental  representation 
and  decision  strategy)  of  the  operator. 

5.  The  unique  contextual  and  environmental  considerations  shall  be  incoiporated  into  the 
design  of  the  ESS  to  support  decision  making. 

6.  When  a  new  ESS  technology  is  introduced,  the  designers  shall  consider  the  possibility  of 
negative  effects  on  team  coordination. 

7.  The  overall  impact  of  an  ESS  shall  be  thoroughly  examined  before  implementation  to 
ensure  that  changes  do  not  result  in  additional  complexities,  loss  of  situation  awareness, 
or  possibilities  for  error. 

8.  The  ESS  shall  keep  an  up-to-date  record  of  where  the  operator  currently  is  within  a 
sequence  of  tasks  or  activities. 

9.  Organize  the  functionality  of  the  ESS  in  line  with  the  operator’s  tasks. 

10.  ESS-related  information  shall  be  structured  according  to  the  operator’s  task. 

Source 

HFDS,  DEFSTD25,  AHCI,  D1SA,  Zachary97,  MS1472F. 

Discussion 

Gl.  An  operator-centered  design  process  is  a  highly  structured,  comprehensive  product 
development  methodology  driven  by  (1)  clearly  specified,  task-oriented  objectives  and  (2) 
recognition  of  operator  needs,  limitations  and  preferences.  Information  collected  using  this 
analysis  is  scientifically  applied  in  the  design,  testing  and  implementation  of  an  ESS.  Defining  the 
goals  and  functions  of  an  ESS  may  require  the  use  of  a  mission,  function  and  task  analysis. 

G2.  Input  from  the  operator  is  essential  in  defining  information  requirements.  To  increase  the 
likelihood  that  the  new  system  will  “fit”  most  operators  and  the  constraints  of  their  tasks,  a 
representative  number  of  operators  shall  be  involved  to  provide  advice  and  feedback  in  the 
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development  of  the  system.  Not  only  shall  this  help  with  system  development,  but  it  shall  also 
give  a  reasonable  number  of  operators  a  feeling  of  “ownership”  which  they  can  transmit  to  their 
colleagues,  thereby  helping  to  facilitate  the  development  of  trust. 

G6.  Automation  of  tasks  may  deplete  team  interaction  and  cooperation  unless  all  parties  are 
provided  with  information  that  allows  them  to  be  actively  involved  in  the  task.  Task  automation 
can  cause  physical  difficulty  in  seeing  what  the  other  team  member  is  doing,  reduce  the  ability  to 
cross  monitor,  change  traditional  roles  and  responsibilities,  and  change  the  manner  in  which  team 
members  attempt  to  help  one  another. 

G8.  This  allows  the  operator  to  resume  tasks  smoothly  and  efficiently  after  being  interrupted. 

G9.  Information  objects  and  operations  shall  be  accessible  in  a  sequence  that  matches  the  way 

operators  will  most  effectively  and  productively  do  things  with  minimal  error. 

G10.  Essential  information  that  is  regularly  needed,  cross-checked,  or  time-critical  should  be 
prominently  displayed.  Less  essential  information  can  be  less  prominently  displayed,  or 
minimized,  pending  examination  at  another  time. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  that  design  methodology  is  compliant  with  MIL-HDBK-46855A  (Human 
Engineering  Program  Process  and  Procedures)  [26] . 

•  Verification  of  system  usability  and  utility. 

Operator  acceptance: 

•  Assessment  of  the  adequacy  of  operator’s  perceptions  of  system  usability  and  utility. 
Relationship  to  other  guidelines 

7.1.1  Employ  operator  centered  principles 

7.2  Employ  operator-centered  OM1  design 

23.2  Adopt  operator-centered  evaluation  principles 

1.  Possible  interactions  with  other  tools,  system  functions,  and  operator  tasks  shall  be 
evaluated  when  a  new  ESS  is  designed. 

2.  New  ESS  components  shall  be  tested  with  the  complete  system,  including  other  system 
components  of  the  ESS,  to  ensure  they  function  together  as  an  effective  whole. 

3.  The  ESS  shall  be  tested  under  normal  modes  of  operation  and  under  failure  modes  of 
operation. 

4.  Contextually  valid  human-in-the-loop  experiments  and  simulations  shall  be  conducted  to 
validate  and  refine  the  ESS  design. 
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5.  Evaluations  of  the  usability  of  the  system  shall  be  carried  out  at  all  phases  of  the  system 
development. 

6.  The  ESS  shall  be  tested  in  a  realistic  operational  environment  using  tasks  and  operators 
representative  of  the  final  system. 


Source 

HFDS,  DEFSTD25. 

Discussion 

G5.  These  evaluations  shall  be  used  both  to  assist  in  deciding  between  alternative  design 
options,  and  to  support  validation  that  the  design  satisfies  the  system’s  operability  requirements. 

G6.  The  tasks  shall  provide  reasonable  coverage  of  the  most  important  parts  of  the  system. 
The  test  tasks  can  be  designed  based  on  a  task  analysis  or  on  a  product  identity  statement  listing 
the  intended  uses  for  the  system. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  that  evaluation  methodology  is  compliant  with  M1L-FIDBK-46855A  (Fluman 
Engineering  Program  Process  and  Procedures)  [26] . 
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24  Training  and  implementation 


24.1  Manage  introduction  of  the  ESS 

1 .  An  ESS  shall  be  introduced  with  advanced  briefing  and  subsequent  training. 

2.  Before  the  ESS  is  introduced,  operators  shall  be  informed  of  associated  changes  and 
increases  in  the  work  effort,  as  well  as  the  benefits  associated  with  the  ESS. 

3.  Operators  shall  be  trained  to  acquire  an  adequate  understanding  (mental  model)  of  how 
the  ESS  works  in  order  to  use  it  effectively. 

4.  Training  programs  shall  stress  human-system  interaction  skills  and  cognitive/problem 
solving  skills  rather  than  psychomotor  skills. 

5.  When  the  ESS  requires  different  kinds  of  cognitive  processing,  ways  of  thinking,  and 
discarding  of  traditional  methods  and  skills,  training  shall  be  designed  to  address 
problems  related  to  these  changes. 

6.  Operators  shall  be  trained  on  what  constitutes  the  normal  ESS  output  so  that  the  operator 
can  easily  determine  whether  the  system  is  functioning  properly. 


Source 

E1FDS,  DEFSTD25  Parasuraman97,  Zachary97,  DISA. 

Discussion 

Gl.  The  introduction  of  the  ESS  may  introduce  changes  in  traditional  roles  and 
responsibilities,  a  redistribution  of  authority  for  tasks  or  changes  to  the  nature  of  the  cognitive 
demands  imposed  on  the  human  operator. 

G2.  The  roles  and  responsibilities  of  the  operators,  cognitive  demands,  and  operational 
procedures  may  change  as  a  result  of  introducing  automation. 

G3.  Operators  must  possess  accurate  mental  models  of  the  system  in  order  to  use  it 
effectively,  comprehend  current  situations,  plan  their  actions,  predict  future  system  states  and 
diagnose  system  failures. 

G4.  Problems  in  automation  may  not  be  inherent  in  the  technology  itself.  Problems  can  arise 
due  to  limitations  in  the  integration  of  the  operator  and  automation. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  that  training  plan  includes  Training  Needs  Analysis  (TNA). 

•  Verification  that  training  plan  compliant  with  MIL-EIDBK-46855A  [26]  guidance  for 
training  (i.e.,  minimize  training  requirements). 


236 


DRDC  Toronto  TR  2009-062 


•  Verification  that  training  plan  includes  regular  training  evaluations. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  operator’s  acceptance  of  ESS. 

•  Subjective  assessment  of  the  adequacy  of  operator’s  perception  of  ESS  usefulness. 

Relationship  to  other  guidelines 

24.2  Train  to  overcome  automation  biases 

24.3  Train  to  overcome  ESS  failures 

24.4  Promote  operator  acceptance  and  trust  in  ESS 

24.2  Train  to  overcome  automation  biases 

1.  Operators  shall  be  trained  to  recognize  inappropriate  uses  of  an  ESS  including 
automation  bias  (the  use  of  automation  in  a  heuristic  manner  as  opposed  to  actively 
seeking  and  processing  information). 

2.  Operators  shall  be  trained  to  recognize  and  understand  the  conditions  under  which  the 
system  may  be  unreliable,  and  to  learn  the  conditions  where  it  performs  well  (when  or 
when  not  to  question  the  automation). 

3.  Operators  shall  be  trained  not  to  become  overly  reliant  on  automation. 

Source 

HFDS,  D1SA,  Parasuraman97. 

Discussion 

Gl.  There  are  different  categories  of  inappropriate  automation  use,  including  automation  bias, 
ignoring  or  turning  off  the  automation,  and  improper  implementation  of  automation.  Operators 
may  rely  on  decision  aids  in  a  heuristic  manner  (referred  to  as  automation  bias).  Using  heuristics 
is  to  apply  simple  decision-making  rules  to  make  inferences  or  to  draw  conclusions  simply  and 
quickly.  Heuristics  are  useful  principles  having  wide  application,  but  may  not  be  strictly  accurate. 
Usually  a  heuristic  strategy  is  optimal,  however,  under  certain  conditions  heuristics  will  be 
inappropriate  and  errors  or  misuse  may  occur.  Automation  bias  leads  to  errors  of  omission 
(failure  to  notice  system  anomalies  when  automation  fails)  and  errors  of  commission  (acceptance 
of  automated  decisions  without  cross-checking  or  in  presence  of  contradictory  information). 
Training  will  help  prevent  automation  bias  and  help  the  operator  learn  to  examine  multiple 
sources  of  information  before  making  a  decision.  Early  training  on  automation  bias  may  reduce 
commission  errors  for  operators  new  to  automation,  but  may  be  less  likely  to  reduce  omission 
errors  or  errors  made  by  expert  operators.  Inappropriate  use  of  automation  may  be  influenced  by 
various  individual  factors  such  as  self-confidence  in  completing  the  task,  trust  in  the  automation, 
differential  effects  of  fatigue,  and  how  all  of  these  factors  combined  weigh  into  the  decision 
making  process.  Inappropriate  use  of  automation  can  be  due  to  misuse  (automation  bias, 
complacency),  disuse  (ignoring  or  turning  off  automation)  or  abuse  (improper  implementation  of 
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automation).The  roles  and  responsibilities  of  the  operators,  cognitive  demands,  and  operational 
procedures  may  change  as  a  result  of  introducing  automation. 

G2.  Operators  must  learn  not  to  categorically  accept  the  recommendation  of  a  decision  aid. 
Understanding  the  automation’s  weaknesses  allows  operators  to  better  judge  how  much  they  shall 
trust  the  automation  without  becoming  overconfident  in  its  performance.  This  recognition  process 
may  impose  an  additional  workload  on  the  operator. 

G3.  When  operators  rely  on  automation  too  much  they  become  susceptible  to  automation- 
induced  complacency.  Monitoring  failures  are  likely  to  occur  when  operators  become  overly 
reliant  on  automation. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  that  training  plan  includes  TNA. 

Operator  decision  making  quality: 

•  Subjective  assessment  of  the  adequacy  of  the  quality  of  the  operator’s  situation  assessment 
processes. 

Operator  trust: 

•  Subjective  assessment  of  the  adequacy  of  operator  trust. 

Relationship  to  other  guidelines 

24. 1  Manage  introduction  of  the  ESS 

24.3  Train  to  overcome  ESS  failures 

24.4  Promote  operator  acceptance  and  trust  in  ESS 

24.3  Train  to  overcome  ESS  failures 

1 .  Operators  shall  be  trained  on  risk  assessment  and  actions  needed  for  risk  reduction. 

2.  Operators  shall  be  trained  on  transitioning  from  the  ESS  to  manual  operations. 

3.  Operators  shall  be  trained  to  ensure  proper  understanding  of  the  ESS’s  processes. 
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Source 


HFDS,  AHCI,  Endsley96,  Parasuraman97. 

Discussion 

G2.  If  the  ESS  was  to  fail,  operators  need  to  be  skilled  at  both  recognizing  the  failure  and 
taking  manual  control. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  that  training  plan  includes  TNA. 

Operator  performance: 

•  Objective  assessment  of  the  adequacy  of  the  operator’s  ability  (e.g.,  speed  and  error)  to 
resume  manual  control. 

•  Objective  assessment  of  the  adequacy  of  the  operator’s  ability  (e.g.,  speed  and  error)  to 
detect  and  manage  ESS  failures. 

Relationship  to  other  guidelines 

24. 1  Manage  introduction  of  the  ESS 

24.2  Train  to  overcome  automation  biases 

24.4  Promote  operator  acceptance  and  trust  in  ESS 

24.4  Promote  operator  acceptance  and  trust  in  ESS 

1 .  Training  shall  be  provided  to  enable  the  operator  to  calibrate  their  trust  in  the  ESS. 

2.  Changes  in  cognitive  processing,  ways  of  thinking,  and  methods  and  skills  used  for  the 
ESS  shall  be  minimized. 

3.  To  promote  operator  acceptance,  operators  shall  be  trained  to  ensure  proper 
understanding  of  the  system’s  processes. 


Source 

HFDS,  DEFSTD25,  MS1472F,  Parasuraman97. 
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Discussion 


Gl.  Training  will  allow  the  operator  to  develop  an  adequate  model  of  how  reliable  or 
unreliable  the  ESS  is  under  specific  conditions. 

G2.  An  ESS  that  requires  different  kinds  of  cognitive  processing,  ways  of  thinking,  and 
discarding  of  traditional  methods  and  skills  may  cause  the  system  to  be  both  less  efficient  and  less 
acceptable  to  the  operators.  This  could  include  automatic  conversion  of  data  into  a  usable  format. 

G3.  The  better  the  operator  understands  the  ESS,  the  more  likely  the  operator  is  to  trust  the 
ESS  appropriately.  Designers  need  to  alter  the  false  belief  that  an  ESS  isperfect  and  ensure  that 
the  operators  understand  when  the  system  is  likely  to  become  unreliable. 

Evaluation  methods  and  measures 

Design  verification: 

•  Verification  that  training  plan  includes  TNA. 

•  Verification  that  training  plan  includes  regular  training  evaluations. 

Operator  acceptance: 

•  Subjective  assessment  of  the  adequacy  of  operator’s  acceptance  of  ESS. 

•  Subjective  assessment  of  the  adequacy  of  operator’s  perception  of  ESS  usefulness. 

Operator  trust: 

•  Subjective  assessment  of  the  adequacy  of  operator  trust. 

Relationship  to  other  guidelines 

24.1  Manage  introduction  of  the  ESS 

24.2  Train  to  overcome  automation  biases 

24.3  Train  to  overcome  ESS  failures 
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List  of  symbols/abbreviations/acronyms/initialisms 


3D 

3 -Dimensional 

ASWC 

Assistant  Sensor  Weapons  Controller 

AWW 

Above  Water  Warfare 

C2 

Command  and  Control 

CPA 

Closest  Point  of  Approach 

CCS 

Command  and  Control  System 

COMDAT 

COMmand  Decision  Aiding  Technology 

DR 

Dead  Reckoning 

DRDC 

Defence  Research  &  Development  Canada 

DRDKIM 

Director  Research  and  Development  Knowledge  and  Information 
Management 

ESS 

Electronic  Support  System 

FAB 

Fast  Action  Button 

FASA 

Factors  Affecting  Situation  Awareness 

IFF 

Identify  Friend/Foe 

INCOMMANDS 

Innovative  Naval  COMbat  MANagement  Decision  Support 

M  button 

Menu  button:  the  right  button  on  a  three-button  mouse  (see  section  9.3.3) 

NASA-TLX 

National  Aeronautics  and  Space  Administration  -  Task  Load  Index 

NOSTP 

Naval  Operations  School  Training  Publication 

NTDS 

Naval  Tactical  Data  System 

OMI 

Operator  Machine  Interface 

ORO 

Operations  Room  Officer 

OSF 

Open  Source  Format 

QAB 

Quick  Action  Button 

R&D 

Research  &  Development 

S  button 

Select  button:  the  left  button  on  a  two-  or  three-button  mouse  (see  section 
9.3.3) 

SA 

Situation  Awareness 

SAGAT 

Situation  Awareness  Global  Assessment  Technique 

SART 

Situation  Awareness  Rating  Technique 

STANAG 

Standardization  Agreement 

SWC 

Sensor  Weapons  Controller 
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T  button 

Transfer  button:  the  middle  button  on  a  three-button  mouse  and  the  right 
button  on  a  two-button  mouse  (see  section  9.3.3) 

TAM 

Technology  Acceptance  Model 

TBM 

Theatre  Battle  Management 

TD 

Technology  Demonstrator 

TDP 

Technology  Demonstrator  Program 

TEWA 

Threat  Evaluation  and  Weapons  Assignment 

TNA 

Training  Needs  Analysis 
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